IT o Security e\o Privacy?

Rispondevo, oggi, ad un post su linkedin:

I ransomware più pericolosi.

1. l’IT manager che sa tutto lui
2. Il CEO che si fida del CFO sui budget IT
3. Il sysadmin che tanto a lui non succede che scoprano che usa P@ssw0rd come password
4. Il backup admin che no fa mai un controllo se i backup finiscono con successo
5. lo stesso soggetto del punto 4 che non ha mai fatto un restore in vita sua
6. lo sviluppatore che se non uso diritti amministrativi non va il mio software
7. il tipo del marketing che deve ricevere e cliccare su tutto altrimenti crolla il mondo
8. il tipo di HR che lui è sopra voi umani e non gli potete mica mettere limiti e controlli
9. quelli che la segregation of duties non va bene nel lavoro smart dove tutti fanno tutto sopratutto lui.
10. tu, si tu, non girarti proprio tu

Incomincio ad avere dei seri problemi quando si parla di security, privacy o GDPR. Il problema nasce dal fatto che diventa fin troppo, a me, evidente che ci si ostina a dare alla sicurezza informatica i compiti di pulizia e sistemazione delle dementi idee partorite in ambito IT (e non solo).

Quello che voglio dire è che security operation e it security o cyber security, privacy e GDPR compliance non devono coprire demenze by deign e by default costruite da idee IT deliranti figlie di soggetti che non hanno capito nulla (nella migliore delle ipotesi), di cosa sia la digitalizzazione

Basta dare alla cybersecurity il compito di coprire deficienze e incompetenze di IT, HR, ed altri compartimenti della azienda. Visti lauti stipendi e responsabilità gerarchiche che tutti inizino a prendersi le proprie resonsabilità. Se non volete farlo, tenete presnte che i recenti orientamenti giuridici sono allienati al mio pensiero, ed in caso di probelmi (non se ma quando) avrete da spiegare le vostre illuminate posizioni ed idee davanti ad un giudice.

Non potete pretendere che responabili CISO e Privacy sappiano tutto, e pagarli, e fornirgli risorse, in maniera ridicola.

Pretendete che gli esperti di security e privacy sappiano di programmazione, prodotti, psicologia, business, legge ma poi non gli riconscete competenze e, sopratutto, fate come vi pare indipendentemente dalle loro indicazioni, ammesso e non concesso che abbiate scelto soggetti relamente indipendenti e competenti.

Duro?

Non abbastanza, se dovessi dire quello che realmente penso prrobabilmente alcuni si potrebbero persino offendere: da CISO che riportano a IT o HR o security manager che hanno esperienza SOLO nella configurazione di firewall ho una secuela di acefale bestialità che non si contano.

Non è la prima volta che esprimo questo concetto, ma recentemente con l’esigenza di home-working venuta fuori a causa del covid e con il crescere del ransomware e phishing la cosa ha assunto problematiche bibicle.

Cerchiamo di capirci, l’IT securtity NON ha il compito di coprire e rimediare le idiozie di disegno di reti e processi pensate da persone, quando va bene, in morte cerebrale.

Se non hai disegnato una politica di backup degna di questo nome non è un probelma di security ma un problema di ignoranza assoluta della questione.

Se le tue password amministrative le sanno anche i criceti non è un problema di security, ma di ottusità alla ennesima potenza.

Se nel codice che hai scritto password e database sono accessibili a chiunque non è un problema di security, è un probelma di incompetenza epigastrica su come si deve scrivere codice.

Se i pagamenti possono essere gestiti da una email senza ulteriori controlli, te lo sei cercato perchè evidentemente non hai idea in che mondo vivi o hai disegnato processi VOLUTAMENTE equivoci per coprire comportamenti non leciti.

Basta dare alla security responsabilità di coprire le idiozie di disegno, implementazione e gestione dei processi e funzioni disegnati da cereblolesi di tutti i paesi,

E basta dire che CEO, CFO, o qualsiasi “C” level non hanno le competenze, perchè non regge.

Neanche di fronte alla legge.

Se sai guidare una macchina, ebbene hai appreso componenti giuridiche procedurali e tecniche ben più difficili di pensare in maniera un minimo sensata ai processi della tua azienda. Se sai usare il tuo nuovo TV 8K smart android allora si di informatica abbastanza per capire concetti impossibili come autenticazione, identificazione, autorizzazione. Quindi le scuse sono a 0.

Quandosi dice che la security è un probelma di processo e non di tecnologia significa che se hai disegnato il processo come lo avrebbe disegnato un bambino ritardato di 3 anni, allora il processo (legale) è quello che ti meriti.

Basta buonsimo e comprensione, si abbia il coraggio di dirlo: molti che si occupano dell’it sono dei dementi. Magari bravissimi su un prodotto ma da qui a saper disegnare processi e tecnologie sensate ne corre.

Molti che gestiscono le aziende hanno la stessa compresione del mondo in cui vivono e la relativa digitalizzazione di un paramecio (con rispetto parlando per i parameci) e se poi falliscono piangono senza capire…tutto tranne che prendersi le dovute e pagate responsabilità.

E diciamocelo una volta per tutte, IT e Security non stanno nella stessa lega. O sei parte della soluzione o sei parte del roblema. Non si può pretendere che vi sia la necessaria indipendenza e competenza se si mette la securty sotto l’IT. Nella migliore delle ipotesi se l’IT è sopra la security chi comanda non avrà interesse a capire cosa la security indica.

E, scusatemi se ho l’ardire di dirlo, security ed IT NON sono la stessa cosa, anzi si sfiorano, hanno elementi di overlapping, ma security ed IT hanno anime, conoscenze e scopi diversi.

E se volessi essere cattivo menzionerei il GDPR e i processi di privacy che NON corrispondono all’IT e NEANCHE alla security.

Lo so che chi legge si divide in 2 categorie:

• Chi capisce già sa e o si rassegna o si incazza ma non si espone (tranne pochi suonati come me)

• Chi non capisce, per lo più, perchè non vuole capire, fino a quando può dare la colpa ad altri…

La realtà è che siamo in un ambito complesso dove la conoscenza specifica di un pezzetto non significa avere la visione di insieme. Ma siccome chi “dovrebbe” avere la visione di insieme si arroga il diritto e l’onere di devidere avendo la visibilità di una minima parte i risultati sono quelli che viviamo oggi.

E siccome chi decide non ammette di aver deciso “male” la colpa, la reponsabilità e e richieste assurde vanno indirizzate su chi non ha ne strumenti ne scopo per risolvere il problema.

La ricetta per un disastro perfetto.

Password, password delle mie brame: chi è la più bella del reame?

"Password password delle mie brame: chi è la più bella del reame?"

"La password più bella è "2bY£4dSàç@°oP7BVù+*oPuHd$5&7=n:@#[6Yx"!\|^ì5%6v£pippo" e non sei tu che sei semplice corta e nota ai più"

"ma dimmi o vate della sicurezza come la ricordo stà schifezza?"

"è semplice e chiaro, il problema sei tu, che non sei un esperto di tutto e di più"

La sciocca filastrocca di sopra mi è venuta in mente leggendo un thread su linkedin:

https://www.linkedin.com/posts/nicola-vanin-b03a5451_password-decifrare-computer-activity-6699248728659824640-jQzw

in cui si sosteneva che una passphrase era meglio di una password complessa ma corta.

il tutto mostrato da questa tabella.

La discussione che ne è seguita è stata interessante per diversi aspetti, alcuni tecnici alcuni ludici, ma la mia impressione in merito è che si è evidenziato, ancora una volta, come gli esperti di sicurezza informatica amino parlarsi addosso e riferire il tutto alla loro conoscenza ed esperienza.

Un Approccio che va a braccetto, spesso, con la mancanza di capacità di astrazione e contestualizzazione. Ci si concentra sul Bit più che su chi il bit lo subisce.

Ora sgombriamo subito il dubbio su alcuni aspetti:

1. computazionalmente non credo che vi siano dubbi sul fatto che più lunga è la password più difficile e decifrarla via bruteforce (tentativi iterativi) anche con sistemi misti con dizionari. la questione matematicamente è stata affrontata tramite il concetto di entropia sui dettagli vi lascio l’ottimo post di Paolo Perego: https://codiceinsicuro.it/blog/entropia-password-e-passphrase
2. tutti concordiamo, spero, che la gestione delle password va al di la della password stessa. L’archiviazione delle password in luoghi sicuri è altrettanto importante quanto la password stessa. Possiamo avere una password lunga a piacere e poi lasciare che sia archiviata dal servizio che usiamo in chiaro, su un database accessibile con poco sforzo su internet. In questo caso la sicurezza è almeno discutibile.
3. Non tutti coloro che usano password sono tecnici informatici esperti di sicurezza, ma c’è sempre da considerare quella sfigata della massaia di voghera usata come cattivo esempio su tutto.

Il punto 3 è quello che mi da più problemi perchè, nella discussione, mi è sembrato sempre mancare questa percezione su chi usa il servizio.

La sicurezza informatica è spesso relegata all’ambito aziendale, nulla di male per carità, peccato che la digitalizzazione dei servizi, anche ludici, si è oramai diffusa ben oltre tale perimetro e quindi occorre iniziare a pensare al fatto che i ragionamenti di sicurezza vanno fatti sul riferimento dei un utente che non è l’esperto di settore.

Un esempio classico è stata la discussione sul remote working (chi lo chiama smart-working si becca una mia personale sequela di improperi), tutti a sollevare correttissime bandierine sul rischio che dalla casa del lavoratore potesse arrivare il mostro che colpiva l’azienda, nessuno, o quasi (io e pochi altri), a valutare l’impatto del rischio verso le pertinenze domestiche del lavoratore remoto. Anche se, chiariamoci, esistono precisi obblighi anche legislativi ed esiste la responsabilità oggettiva in caso di danneggiamenti alle proprie pertinenze o alla propria riservatezza (GDPR docet).

La discussione sulle password si è svolta in maniera analoga, in pura assenza di contesto che non sia quello della propria personale competenza ed esperienza, al punto di negare un punto banale come quello del punto “1”.

Fatevene una ragione, ma sistemi complessi di gestione password non sono di facile implementazione se allarghiamo la platea al di fuori del perimetro aziendale, e quindi guide e supporto in tal senso per il grande pubblico sono necessarie.

Imporre una lunghezza minima per passphrase di 20 caratteri è differente da dare la password minima a 8. E se pensate che l’utente medio usi password managers da telefonino per gestire password complesse vivete probabilmente su un pianeta diverso dal mio.

Quindi obiettare che non è vero che una password mnemonica più lunga sia più sicura rispetto ad una di 10 con caratteri speciali, lettere maiuscole e minuscole è vero nella misura in cui non si considera l’utilizzatore.

Per chi ha una minima familiarità col social engineering probabilmente queste cose sono note, ma tant’è.

Più le password sono complesse meno l’utente medio è portato ad usarle in maniera univoca, inoltre l’esigenza di ricordarle porta alla loro utilizzazione in maniera semplificata, a tutto vantaggio, ad esempio, di dictionary attack.

Se si da una lunghezza minima questa sarà per lo più quella usata dalla maggior parte degli utenti, aumentare il numero minimo di caratteri in questo senso aiuta più che tante prediche.

Più la password è complicata più aumenta il senso di frustrazione degli utenti e la loro intolleranza, la usability anche se non vi piace va tenuta in contro perchè poi incide sui sistemi di sicurezza in maniera pesante, basta pensare che tutti sono informaticamente savi.

Tra una password di 20 caratteri ed una di 10 c’è un fenomeno psicologico interessante che porta utente a sentire meno il peso di introduzione di una passphrase mnemonica perchè la quantità di caratteri consente anche frasi di senso compiuto più facili da ricordare rispetto ad un astruso set da 10 caratteri.

Molte delle tecniche suggerite (cambi posizionali, uso di semplici algoritmi di sostituzione) NON sono alla portata di molti utenti. E piantiamola di credere che non sia cosi, se candidati manager di una PA si lamentano di un test con problemi di terza media pensate davvero che un utente che usa in maniera ludica il computer si metta a fare certi ragionamenti?

I password manager, estremamente gettonati nel thread che ha dato origine a questo post, altrettanto non sono una garanzia per diversi motivi, al di la dei rischi connessi a quelli cloud va da considerare anche il fatto che molti utenti neanche immaginano cosa siano.

Insomma intavolare una discussione sulle password senza tener in conto chi le password le immette rischia di trovare una soluzione ottima ma inutilizzabile ai più, con le relative conseguenze.

my 2 cent ovviamente

Email Defense: Registrazione preventiva di un dominio

Oggi come oggi la maggior parte degli attacchi che riceviamo arrivano via email e via social media.

La ragione è ovviamente legata al fatto che sono i due canali di comunicazione piu usati da tutti noi sia a livello personale che a livello aziendale. Nella nostra posta e nei nostri social ci sono amicizie, contatti di lavoro, ropietà intellettuale e chi piu ne ha piu ne metta.

Purtroppo la immediata conseguenza del successo di questi canali e l’uso da parte di male intenzionati che sfruttano la facilità estrema con cui è possibile portare attacchi su questi vettori. Mandare una mail o scrivere un post sono attività semplici che non richiedono grandi sforzi, e spesso techiche di social engineering sviluppate su questi canali risultano estremamente efficaci.

Uno dei problemi spesso non considerato che questi attacchi (Phishing, BEC, Impostor) spesso arrivano da domini che assomigiano a quelli originali. I metodi vanno dal typosquotting (scrivere il nome in maniera simile) al registrare domini in altre nazioni. In questo tipo di attacco ci sono 2 vittime, chi riceve la email e viene ingannato e chi si vede il dominio “usato” a sproposito. Insomma quando riceviamo il solito phishing di “postecom” ci lamentiamo ma sotto sotto pensiamo male anche del mittente anhe se sappiamo essere fasullo.

Vi sono diversi accorgimenti che un propietario di un dominio di posta puo utilizzare per difendersi.

Uno degli strumenti pricipe è l’utilizzo coerente e concreto dei protoclli di email authentication come SPF, DKIM e DMARC.

L’implementazione di questi protocolli sui domini di posta che effettivamente mandano posta è di indubbia utilità, ma sarebbe opportuno iniziare a pensare anche di utilizzarli per la registrazione difensiva di domini.

Questi domini sono spesso utilizzati per evitare che vengano usati da “terzi” sfruttando il brand originale per scopi piu o meno leciti, ma spesso lasciano il fianco scoperto a chi vuole utilizzarli per inviare phishing o attacchi di email.

I protocolli di email authentication in questo frangente diventano utili per minimizzare il rischio di uso improprio di un dominio registrato per motivi difensivi (e che non dovrebbe inviare posta).

Una registrazione SPF con “v=spf1 -all” e una registrazione DMARC con un Reject per quei domini risulta un buon deterrente.

In particolare la registrazione SPF è facile e non costosa, non vi sono ragioni per non ponerla come policy “obbligatoria” nelle procedure di registrazione di fensiva di domini.

Guida al GDPR per chi non ne vuol sapere: raschia raschia rimane il rischio ?

Ma se ti dico “rischio” tu che mi rispondi?

Er… no non intendo la sequela di insulti o le minacce più o meno velate a cu stai quasi sicuramente pensando, stavo cercando di parlare di GDPR…

No, no, GDPR non è una parolaccia, calmiamoci.

Insomma volevo solo chiedere che cosa associate alla idea di rischio indicata dal GDPR.

Ne parlo qui perché ultimamente ho avuto modo di vedere come molti non hanno bene chiaro cosa sia questo fantomatico rischio di cui si parla.

Allora cerchiamo di fare un poco di chiarezza ad un livello che persino io possa capire di cosa stiamo parlando, quindi estremamente basso.

Genericamente quando parliamo di rischio facciamo riferimento alla eventualità di subire un danno (più incerto di quello implicito in pericolo).

In termini estremamente generici questo significa dover analizzare una serie di cose associate ad un evento che comporti rischi:

• la prima è: chi subisce il danno
• la seconda è: l’entità del danno
• la terza è: la probabilità che l’evento si possa verificare.

Il primo punto è fondamentale, i quanto il soggettooggetto del rischio determina pesantemente le altre due occorrenze sia in termini di valutazione quantitativa che qualitativa e quindi guida le scelte rivolte a ridurre, mitigare il rischio, trasferirlo o comunque gestirlo in toto o la sua parte residua.

Il secondo punto afferisce alla entità del danno. A seconda del tipo di rischio che stiamo analizzando l’entità viene solitamente parametrizzata attraverso valori di facile lettura, come ad esempio la perdita economica associata.

Il terzo punto va ovviamente ad indirizzare la esigenza di calcolare quante possibilità ci siano che l’evento infausto che causa il danno possa accadere. Laddove ci fosse la certezza non si parlerebbe di rischio e quindi le analisi di cui sopra sarebbero inutili e parleremmo, semplicemente, di pericolo.

L’analisi del rischio ci consente di mettere in atto quelle procedure e comportamenti che possano minimizzare gli effetti dannosi. Questo può essere effettuato attraverso diverse scelte NON mutuamente esclusive tra di loro.

Ad esempio:

• Si può scegliere di indirizzare gli sforzi in direzione dell’abbassamento dell’entità del danno subito in caso di evento infausto
• Si può scegliere altrimenti di indirizzare gli sforzi in direzione dell’abbassamento della probabilità che l’evento infausto possa accadere.

Potrebbe accadere che uno specifico evento si possa semplicemente eliminare dalla nostra tabella dei rischi a seguito delle azioni intraprese ma più spesso accade che i costi per l’eliminazione del rischio siano così alti che conviene invece accettare un rischio residuale.

Le azioni per abbassare il rischio possono essere ad esempio di mitigazione (vedi i due punti precedenti) o di trasferimento.

La soglia di accettabilità del rischio dipende ovviamente da valutazioni soggettive e oggettive e dipende dall’ambito di cui stiamo parlando.

Non esiste azione umana che sia esente dal rischio, ma la percezione e l’accettazione del rischio dipende ovviamente dal dominio cui stiamo facendo riferimento.

Ok ok ti sei annoiato con cose che sai benissimo meglio di me, anche se non sai di saperle (dopotutto tutti attraversano la strada e quindi gestiscono rischi….)

Torniamo al GDPR.

Il rischio in termini di GDPR è il rischio di danneggiare la privacy e le libertà fondamentali di un soggetto.

Usando i tre punti di cui si parlava all’inizio del mio sproloquio potremmo dire che:

chi subisce il danno è l’utenteutenti i cui dati personali vengono in qualche maniera indirizzati dall’evento in analisi (copia, cancellazione, modifica e via dicendo)

l’entità del danno è quanto l’utente possa essere danneggiato dall’evento specifico ed è, ovviamente, legato alla natura dei dati in oggetto e a quello che a questi dati è accaduto.

La probabilità che l’evento infausto possa accadere è invece legata ai processi in uso per la gestione dei dati raccolti.

Non facciamo i soliti errori per favore:

Innanzi tutto per poter implementare correttamente il GDPR occorre fare una valutazione del rischio implicito nella gestione dei dati personali, utilizzando come riferimento quello descritto sopra.

Chi deve fare queste valutazioni è chi si occupa di questa cosa. In ultima analisi spetta al responsabile dell’azienda utilizzando il DPO quando presente come fonte autorevole di indicazioni in merito.

Spetta al responsabile aziendale o “data controller” quindi decidere:

• quale sia il rischio residuo accettabile
• quale siano le azioni da intraprendere per mitigare, minimizzare i rischi legai al GDPR.

Questa cosa è di fondamentale importanza da capire. Nella nomenclatura del GDPR il Data controller o responsabile della gestione dei dati personali è la fonte delle decisioni. Il o i data processor pur condividendo una responsabilità operativa nella gestione della sicurezza del dato non sono responsabili delle scelte operate per proteggerli come tali.

Come a dire che non sta alle strutture IT decidere cosa fare, al più all’IT possono essere demandate le scelte implementative, una volta individuata la via di mitigazione che il “data Controller” ritiene più adatta ad abbassare la soglia di rischio fino ad un livello di rischio residuale accettabile, laddove queste richiedano una opzione tecnologica e non di processo.

Questa osservazione implica la comprensione di una cosa non sempre chiara in chi si occupa di GDPR:

il rischio in termini di GDPR è cosa diversa dal rischio di Business o dal rischio di Cyber Security.

Mescolare questi 3 domini assieme senza avere chiara a distinzione tra i 3 tipi di rischio comporta semplicemente l’indirizzamento verso scelte errate in quanto:

o non indirizzano la natura del rischio in oggetto (e quindi rappresentano una duplice voce di costo in termini di spese effettuate inutilmente e di rischio ancora presente)

o non mitigano correttamente tale rischio entro la soglia di accettabilità (rischio residuo accettabile).

o portano a scelte non ottimali e quindi più costose rispetto il necessario.

Purtroppo la non esatta comprensione del GDPR sta portando molte aziende a vedere la cosa solo in termini meramente tecnologici, associando il rischio GDPR al rischio tipico della Cyber Security. Questo rischia di far intraprendere alle aziende percorsi errati o eccessivamente onerosi.

Ma che differenza c’è?

Per capire la differenza tra un rischio di cyber security, di business e di uno legato al GDPR occorre pensare attentamente alla natura intrinseca del rischio in senso del GDPR.

Il GDPR si preoccupa delle libertà fondamentali dell’individuo espresse attraverso la difesa della sua “privacy”.

Ora prendiamo un paio di eventi esemplificativi dei domini di Cyber Security: DoS (Denial of Service) e attacco Ransmomware.

L’attacco  dDos

In caso di attacco DoSdDoS che blocchi una struttura, siamo in presenza di un evento dannoso che potrebbe impattare il business di una azienda nel caso colpisca, ad esempio, una interfaccia di e-commerce o una di mera presenza marketing online.

Dal punto di vista del business a seconda della interfaccia impattata le valutazioni di rischio potrebbero essere diverse ma potremmo dire che, se siamo in presenza di un attacco su di una interfaccia di E-commerce l’impatto (ed il rischio) è alto mentre in caso di una interfaccia di puro marketing potrebbe essere di medio livello

Dal punto di vista meramente Cyber, un attacco Dos è tanto più grave quanto maggiore sia la probabilità che esso avvenga e che impatti diverse strutture. In caso di un attacco ad un servizio online di E-commerce siamo in presenza di tutti gli elementi per definirlo un rischio elevato (probabilità, impatto, facilità di attacco….), ma la stessa analisi vale per un sito marketing. Dal punto di vista cyber quindi abbiamo valutazioni discordanti rispetto a quello di business.

Ora se ci mettiamo nei panni del GDPR in entrambi casi il rischio di esposizione dei dati dell’utente sono minimi o nulli, dono quindi in entrambi i casi eventi di basso rischio in termini di GDPR che potrebbero quindi essere considerati accettabili in termini in di rischio residuale.

 

L’attacco Ramsonware

Ricordate wannacy? Giusto per nominare l’ultimo?

In caso di business gli effetti di un ransomware che attacchi, ad esempio, le strutture di billing potrebbero essere disastrose, mentre l’attacco ad una serie limitata di PC potrebbe essere ininfluente.

Dal punto di vista Cyber invece la probabilità di attacco ad un terminale di un utente è più alta, e potenzialmente potrebbe dare adito ad attacchi diffusi interni, ne consegue che dal punto di vista cyber ci si potrebbe attendere addirittura una valutazione più alta di rischio sul pc dell’utente che sul sistema di billing.

Dal punto di vista del GDPR se sono in piedi processi che consentano il recupero dei dati in tempi accettabili (non è richiesta la immediatezza) un ransomware presenta un livello di rischio medio ed addirittura basso nel caso di un sistema di billing che tenga le anagrafiche separate (e quindi non impattate dall’attacco cui stiamo facendo riferimento nell’esempio.

 

È interessante notare che data la diversa natura del rischio anche le azioni di mitigazione da intraprendere sono diverse nei due casi a seconda del tipo di rischio di cui parliamo.

Nel caso del ransomware, ad esempio, dal punto di vista del GDPR potrebbe essere sufficiente una buona struttura di backup isolata dal sistema, mentre nel caso di business la business continuity richiederebbe una serie ben diversa di sforzi implementativi.

Mescolare e fare confusione non è una buona strada da seguire.

Fare confusione sui diversi domini di rischio, anche se afferenti ad un medesimo evento, può portare a scelte non corrette di mitigazione eo trasferimento.

Se questo è vero in generale, nel caso del GDPR assume un significato ancora più grande in quanto occorre capire che il soggetto a rischio è esterno alla azienda e quindi le azioni da intraprendere sono concettualmente diverse.

Non definire sin dall’inizio le responsabilità e modello di calcolo del rischio comporta scelte, nella migliore delle ipotesi, sbagliate.

 

Meditate gente meditate

Ciao

Antonio

 

 

 

 

 

 

Caro HR Manager: Storia di un CV e della sua privacy (GDPR lo dici a tua sorella)

Sono un poco preoccupato, perché la mia impressione è che in Italia, a fronte di una delle legislazioni più severe d’Europa e i nuovi vincoli introdotti od in via di introduzione dal GDPR, il concetto di privacy sia altamente sottovalutato.

Il problema ovviamente è insito nella storica sottovalutazione italica dell’impatto delle strutture informatiche all’interno dei processi produttivi, decisionali e manageriali.

Insomma non ci si interessa, non si capisce, e non si valuta. Di conseguenza non si correggono comportamenti errati e, allo stesso tempo, non si sfruttano le nuove possibilità rimanendo al palo delle nuove tecnologie con buona pace di chi (da Olivetti a Faggin, ma potremmo citare Marconi e Meucci) avevano fatto dell’Italia la piattaforma del nuovo.

Vabbè

Polemiche parte vediamo di capire con un esempio così semplice che persino un ufficio HR potrebbe capire, cosa significa gestire la privacy e la protezione del dato.

Ti arriva un nuovo CV: cosa hai capito della privacy e del GDPR?

Immaginiamo che il vostro ufficio HR riceva un CV di un possibile candidato. Cosa non tanto strana in tempi in cui la ricerca del lavoro è fondamentale (anche io ne ho mandati in giro centinaia recentemente).

Immaginiamo anche che il CV arrivi via posta elettronica (cosa abbastanza consueta) e che giusto perché ci sono posizioni aperte il medesimo venga fatto girare tra qualche potenziale interessato. Ad esempio l’hiring manager.

Non mi interessa in questo momento sapere come finirà la storia dell’essere umano dietro quel pezzo di carta, con i suoi bisogni, aspirazioni e potenziale. Mi interessa proprio il pezzo di carta, virtuale.

Come potete immaginare quel pezzo di carta contiene dati personali, in quanto sono riferibili ad una persona fisica.

OPS va a finire che per questo devo trattarli in maniera coerente alle disposizioni di legge? Va a finire che il GDPR (qualunque cosa esso sia) viene convolto?

Temo proprio di si.

CV, CV che farne?

Allora in teoria, ammesso e non concesso che tu sia interessato in qualche maniera ad essere allineato ai dettami di legge, dovresti processare questi dati di conseguenza.

Non voglio qui fare una dissertazione di dettaglio sul GDPR, ma mi limito ad alcune considerazioni banalotte, giusto per aiutarti ad evitare una multa salta.

Il cv in questione probabilmente finirà in:

• Diverse caselle di posta
• Come file in qualche cartella personale eo condivisa
• Magari in un database se sei abbastanza grande da memorizzare i cv dei candidati
• Stampato su qualche scrivania
• ….

Ora siccome quel pezzo di carta (virtuale e non) contiene dati personali, e magari sensibili (che so il tuo ultimo stipendio, il tuo IBAN, l’indirizzo della tua amante … ) tu che lo ricevi dovresti avere in piedi un processo di gestione che tenga presente che questi dati devono:

• essere conservati in maniera sicura
• deve essere possibile per il proprietario dei dati (che non sei tu, è il tipo che ha scritto il cv) chiederne la modifica
• deve essere possibile per il proprietario dei dati (ancora non sei tu) la cancellazione.
• Dovresti anche essere in grado di determinare quale sia la vita, all’interno dei tuoi sistemi, di questi dati e l’uso che ne fai.
• …

Che tu ci creda o meno questo richiede di avere dei processi definiti che riguardano la “vita” di quel coso che so, adesso, incominci ad odiare.

Insomma dovresti sapere cose del tipo (tra loro strettamente correlate):

per quanto tempo tengo questa cosa nei miei sistemi?

Come salvo questi dati?

Come li cancello?

Sembra facile ma tu sai veramente che succede ai CV che ricevi?

Hai definito una “retention policy” su questi dati?

Traduco, hai una regola standard che definisce quanto tempo puoi tenere questi dati? Mesi? Anni? Lustri? Per sempre? Ma che @#?§ vuoi che me ne freghi ammé?

Ok la ultima e la tua policy attuale lo so, ma temo non sia la risposta che meglio si adatta alla nostra legislazione.

Quanto tengo quell’oggetto ed i relativi dati in casa è importante perché:

• Il dato, fino a che lo tengo, va gestito, conservato, protetto secondo legge
• Ne sono legalmente responsabile
• Quando lo cancello lo devo fare davvero

Ora il punto uno è già un punto dolente. Significa che tu dovresti sapere questa roba dove si trova nei tuoi sistemi. E non importa se in forma cartacea o elettronica….

Il punto è dolente anche perché ti impone di utilizzare tecniche coerenti per la protezione, salvataggio, recupero ed accesso al dato.

Insomma vediamo se riesco a spiegartelo: se lo salvi in un database o lo metti su una cartella, devi garantire in qualche maniera che l’accesso non sia concesso proprio a chiunque, anche all’interno della azienda.

Se poi ha iniziato a girare via email so che può essere complicato evitare che vada ovunque quindi, magari, sarebbe opportuno che queste cose le sappiano tutti in azienda, non solo lo sfigato di turno che deve farsi carico di sta roba pallosa che è la privacy.

Insomma di a chi lo ha ricevuto che va trattato in maniera adeguata, magari cancellandolo se non serve più, altrimenti come garantisci la adeguata protezione ed il ciclo di vita?

Poi, ovviamente, l’IT dovrebbe garantire la protezione anche da intrusioni esterne:

qualcuno la chiama cyber security,

altri sicurezza informatica,

tu “quelle cose li da tecnici che non ci capisco niente però ho l’antivirus che non aggiorno da 6 mesi perché mi rallenta il computer”

tu “quelle cose li da tecnici che non ci capisco niente però ho l’antivirus che non aggiorno da 6 mesi perché mi rallenta il computer”

In teoria dovresti anche avere sistemi di salvataggio e recupero adeguati. Una roba che si chiama backup e recovery, magari ne hai sentito parlare l’ultima volta che hai perso tutti i tuoi dati …

Il tutto perché se non lo fai e, disgraziatamente, ti becchi un ransomware, o ti entrano nei sistemi e finisci sui giornali perché hanno pubblicato la foto dell’amante che il tuo candidato che aveva messo sul cv, qualcuno che ti ha mandato il cv potrebbe porsi domande e chiedere conto delle tue azioni, e sai la cosa brutta quale è? … che non è tutta colpa dell’IT (fonte di tutti i mali, notoriamente) secondo la legge …

Lo odi sempre più sto cv vero?

Pensa che la cosa è ancora più complicata perché: si qualcuno si deve far carico dei backup, testare di tanto in tanto i restore.

Roba che il buon Monguzzi non finisce mai di ricordarci, ma che puntualmente ignoriamo J

Ma lasciami aggiungere un altro pezzettino. Se il dato lo cancelli deve essere cancellato davvero. Questo significa la cancellazione di tutte le copie presenti in azienda:

• email
• dischi
• database
• backups
• …

Lo sapevi? No?

Se non lo sai sallo!

 

Privacy e gestione del dato

So di essere controcorrente scrivendo queste cose, e che hai cose molto più importanti a cui pensare. Ma se volessi potrei continuare parlando al tuo marketing, al tuo ufficio vendite, al tuo ufficio acquisti, a chi ti gestisce il sito web e probabilmente anche al tuo IT manager che se gli si dice GDPR risponde a te e tua sorella!

 

probabilmente anche al tuo IT manager che se gli si dice GDPR risponde a te e tua sorella!

Il punto è che queste cose sembrano complicate, ma in realtà non lo sono davvero. Basterebbe capire cosa significa integrare i dati nei processi aziendali, e disegnare i medesimi tenendo conto delle esigenze di legge, di business e della tecnologia corrente.

Certo significa anche che non puoi trattare la privacy come una rottura di scatole che non ti riguarda, esattamente come non dovresti fare con l’IT.

Pensaci e se eviterai una multa forse mi ringrazierai anche, finita la sequela di improperi che mi sono meritato per averti detto queste cose.Ciao

Sicurezza: ritorno alle basi

Dando una occhiata alle diverse riviste di settore ci si può rendere conto di quanto la sicurezza informatica sia diventata importante. Non solo si sono moltiplicati i vendor e le tecnologie, ma le informazioni sul fenomeno si sono diffuse e adesso entrano a far parte anche del lessico di quotidiani e magazine non specialistici.

Ma quanto questo parlare ha aumentato la consapevolezza?

Una serie di suggerimenti interessanti può venire dalla lettura del nuovo rapporto 2014 Clusit, l’Associazione Italiana per la Sicurezza Informatica (Clusit).

Il documento che prende in considerazione oltre 2.800 incidenti avvenuti negli ultimi 36 mesi e si avvale dei dati forniti dal Security Operations Center di Fastweb. Il Rapporto identifica il cyber-crimine come la causa principale (più del 50 per cento) dei cyber-attacchi registrati durante tutto il 2013.

Si tratta di una crescita del 258 per cento rispetto al 2012 mentre si fanno strada fenomeni relativamente nuovi come hacktivismo (+22,5 per cento) e spionaggio informatico/telematico (+131 per cento). Le tecniche preferite dai cyber-criminali includono attacchi DDoS, cracking di account e Advanced Persistent Threat (APT) mirati verso organizzazioni specifiche.

L’aumento vertiginoso è frutto di tre fenomeni due “negativi” ed un terzo “positivo”:

• L’aumentato valore economico di tali attività, che spinge la malavita ad orientarsi verso nuove forme di arricchimento illecito.
• Lo stato di obsolescenza di gran parte delle strutture informatiche italiane, con un particolare deficit nei confronti della sicurezza sia in termini di tecnologie adottate che di creazione di processi interni di gestione
• Un aumento della sensibilità che porta all’emergere di una serie di eventi che prima rimanevano nascosti tra le mura delle entità attaccate, aumentando gli ostacoli ad una corretta presa di coscienza del fenomeno.

Risulta particolarmente interessante notare come i 3 principali temi di attacco risultino essere di tipo abbastanza noto nei primi due casi, e di nuova generazione nel terzo.

DDoS e Cracking di account sono in effetti storicamente tra i più vecchi metodi di attacco utilizzati, e sia la letteratura che le notizie dal mondo della sicurezza informatica riportano clamorosi casi di violazione di database di account o di blocchi di siti.

DDoS la base dell’acktivism

Gli attacchi DDoS hanno infatti preso posto nelle cronache a seguito di alcuni episodi legati a fenomeni di attivismo online di gruppi quali anonymous o lulzsec. Assieme al deface, il blocco parziale o totale di siti è stato infatti uno strumento particolarmente utilizzato, addirittura con la distribuzione diffusa di software come LOIC (Low Orbit Ion Cannon) altrimenti in uso dagli “addetti ai lavori”.

La diffusione e relativa facilità con cui è possibile procedere ad un DDoS non è passata inosservata neanche alle bande di Cyber criminali che hanno trovato in questo un interessante strumento per ricattare vittime minacciando blocchi dei servizi web. I target di questo tipo di ricatto sono stati inizialmente siti di vendite online e, soprattutto, di scommesse. Pur esistendo tecnologie anti DDoS da anni il parco implementato di soluzioni in Italia è ancora desolatamente basso. Sia dal punto di vista delle tecnologie di networking che dal punto di vista della protezione di servizi chiave (si pensi ai servizi DNS) nonostante vi sia una offerta di mercato interessante dal punto di vista qualitativo il mercato italiano è ancora decisamente restio ad affrontare tali implementazioni, anche perché oltre alla richiesta economica vi sono richieste in termini di processi da affrontare, al fine di non far diventare questi strumenti oggetti belli ma fondamentalmente inutili perché non gestiti nella maniera corretta, fine che hanno subito nel nostro paese anche molte implementazioni IPS\ISD e SIEM.

Cracking di account

Le basi della informatica (e della sicurezza) insegnano che la prima attività che ha in carico un utente per poter accedere ad una struttura informatica è quella di effettuare il login. Nella maniera più diffusa questo viene fatto attraverso la coppia di dati username e password.

Sono oramai diversi anni che gli esperti di settore fanno notare come questa modalità di ingresso nella rete sia di tipo poco sicuro, in particolare l’uso delle password risulta essere spesso un vero e proprio tallone di Achille in termini di sicurezza. Le password comuni sono spesso facili da “craccare” anche attraverso elementari servizi di brute forcing, ma l’uso di password complesse risulta spesso intollerabile agli utenti che tendono a evadere i vincoli con strutture facilmente ripetibili. Un altro problema dell’uso delle password è che all’aumentare del numero di password richieste aumenta la tendenza ad unificarle indipendentemente dal tipo di servizio cui si accede. La password aziendale cosi è spesso utilizzata anche come password per accedere alla propria webmail o al proprio social network, esposti a continui attacchi ed hack.

Soluzioni di strong authentication esistono sul mercato da parecchio, ma oggi prodotti che integrano one time password generation ai sistemi di log-in sono diventate economiche, multipiattaforma e grazie al diffondersi dell’uso di app non richiedono più nemmeno la famosa “chiavetta”.  Anche in questo caso purtroppo in Italia il livello di implementazione è ancora troppo basso rispetto a quello che accade al di fuori dei nostri confini.

APT: non si bloccano se non ci sono le basi

“Dulcis in fundo” (o forse più correttamente dovremmo dire “in cauda venenum”) troviamo l’emergere del fenomeno APT, da una pressante campagna informativa da parte dei vendor di sicurezza informatica, quale nuova frontiera della protezione delle nostre reti.

Il fenomeno APT è un fenomeno estremamente complesso, e soluzioni magiche che ne indirizzino tutti gli aspetti non sono pensabili se non in termini di service che copra tutti gli aspetti della struttura IT. I prodotti presenti oggi offrono strumenti di protezione estremamente sofisticati che, però, necessitano a monte di una struttura adeguatamente preparata in termini di tecnologie e processi. L’APT nasce da una serie di attività che vanno dal social engineering al più tradizionale sfruttamento di una vulnerabilità per ottenere un accesso. Le stesse attività di DDoS e Account cracking possono essere in realtà componenti di un APT e richiedono attenzioni specifiche.

Quello che i dati ci dicono quindi è che il fenomeno non è più un oggetto di folclore ma che la sicurezza informatica incomincia ad essere un fenomeno che deve interessare la massa degli utenti IT e non solo poche realtà particolari. Un interesse che deve essere accompagnato dalla introduzione\implementazione di practice e tecnologie coerenti per poter essere efficaci. Non serve dotarsi della più sofisticata porta blindata se si lasciano aperte le finestre.

 

 

 

Advanced Persistent Threat

Advanced Persistent Threat: come muoversi tra il marketing e la realtà?

Questo post riporta le immagini della presentazione che ho tenuto al Festival ICT il 6 di novembre. oltre al post metterò su slideshare a disposizione anche l’intera presentazione in visione sperando di fare cosa gradita.

Ovviamente le prime due slide sono introduttive, la prima rappresenta il titolo, l’orario ed il numero della sala 🙂 nella seconda abbiamo la grande opportunità di vedere anche la mia foto e la mia e-mail come referenza per chi fosse interessato.

Vi tralascio la descrizione della animazione di transizione tra una slide e l’altra (per gli interessati, origami) e passiamo a cose più serie 🙂

La domanda che ho posto è: ma noi sappiamo, o abbiamo capito esattamente cosa significhi APT? Di APT si parla molto sul mercato ed i vendor di sicurezza ne fanno ultimamente uno dei loro cavalli di battaglia , ma abbiamo realmente capito di cosa si tratta? APT come sigla in realtà può significare tantissime cose, e ne avete sulla destra breve elenco.

Per prima cosa occorre quindi capire cosa significhi relamente APT e da questo punto possiamo partire ad analizzare l’offerta di mercato.

Se prendiamo la definizione di APT come Advance Persistent Threat scopriamo che è una cosa ben precisa. le tre parole significano:

Advanced: si tratta di un attacco dove l’attaccante utilizza tutte le tecnologie utili al risultato: da un semplice uso di vulnerabilità note alla creazione o scoperta di vulnerabilità specifiche, si tratta quindi di una forma di attacco estremamente sofisticata che utilizza risorse e tecnologie coerenti con lo scoppo dell’attacco e la struttura dell’attaccato:

—Advanced means the adversary can operate in the full spectrum of computer intrusion. They can use the most pedestrian publicly available exploit against a well-known vulnerability, or they can elevate their game to research new vulnerabilities and develop custom exploits, depending on the target’s posture.

Persistent: significa che l’attacco è un attacco motivato, e non un attacco casuale su un bersaglio randomico. il significato di “persistent” non è quindi che si tratta di un attacco ripetitivo, ma di un attacco ove l’attaccante insiste con le tecnologie opportune per arrivare al suo obiettivo.

—Persistent means the adversary is formally tasked to accomplish a mission. They are not opportunistic intruders. Like an intelligence unit they receive directives and work to satisfy their masters. Persistent does not necessarily mean they need to constantly execute malicious code on victim computers. Rather, they maintain the level of interaction needed to execute their objectives.

Threat: significa che l’attacco non è un atto meccanico o casuale, ne un malware generico ma un soggetto determinato con un piano e risorse.

—Threat means the adversary is not a piece of mindless code. This point is crucial. Some people throw around the term “threat” with reference to malware. If malware had no human attached to it (someone to control the victim, read the stolen data, etc.), then most malware would be of little worry (as long as it didn’t degrade or deny data). Rather, the adversary here is a threat because it is organized and funded and motivated. Some people speak of multiple “groups” consisting of dedicated “crews” with various missions.

 

 

Il target di un APT può essere in realtà qualsiasi, non esiste un mercato specifico, obiettivi militari, politici, economici anche in senso lato possono giustificare un APT. va anche considerato che un APT è può prevedere anche attacchi multipli su soggetti diversi, per motivi che possono essere i più diversi, dal aumentare il “rumore di fondo”, a distrazione o copertura del vero bersaglio.

Già dalla definizione è quindi chiaro capire come sia poco plausibile che esistano prodotti specifici contro gli APT, in quanto un APT non definisce a priori un attacco specifico, ma una tipologia di attacchi che utilizza tecnologie multiple e complesse.

Un APT è quindi più correttamente espresso come un processo, una successione di passi che partono dalla definizione di un bersaglio allo sviluppo di uno o più attacchi veri e propri.

Visto che non tutti masticano l’inglese ho riportato la definizione di APT data dal NIST, ma tradotta in italiano:

“La minaccia avanzata persistente è un avversario con livelli sofisticati di competenza e risorse significative, che gli consentono, attraverso l’utilizzo di vettori di attacco multipli (come frode e metodi informatici e fisici), di generare opportunità per raggiungere i propri obiettivi: questi consistono tipicamente nello stabilire e ampliare punti di appoggio all’interno dell’infrastruttura informatica delle organizzazioni, allo scopo di derivarne informazioni in modo continuativo e/o di compromettere o ostacolare aspetti critici di una missione, programma o organizzazione, o di mettersi in condizione di farlo in futuro. Inoltre, la minaccia avanzata persistente persegue i propri obiettivi ripetutamente per un periodo di tempo prolungato, adattandosi agli sforzi di un difensore per resisterle, e con lo scopo di mantenere il livello di interazione necessario per eseguire i propri obiettivi”.

Essendo quindi un APT più propriamente un processo, occorre quindi capire quali siano gli step principali per riuscire a comprendere quali tecnologie, eventualmente, possano essere di supporto alla difesa di attacchi simili.

Il primo passo di un APT è sicuramente la definizione del bersaglio, con definizione si intende la identificazione del soggettoi da attaccare, le linee guida dell’attacco e gli obiettivi. Esattamente quello che faremmo per la definizione di  un progetto 🙂

La definizione di un bersaglio quindi  richiede che siano fissati obiettivi e strategie che sono dipendenti dalla natura del bersaglio stesso e dagli scopi che spingono l’attaccante. Abbiamo detto prima che esiste una moltitudine di bersagli, mercati e scopi, le considerazioni tattiche e strategiche sono quindi molteplici ed afferiscono in larga parte a questa fase.

 

In linea di massima però possiamo suddividere questo processo in almeno tre fasi chiave:

identificare il soggetto o i soggetti target, o le motivazioni degli attacchi

definire gli obiettivi in termini di cosa colpire, come e perchè

definire una strategia, compreso il tempo entro cui effettuare la operazione, le risorse da impegnare, il gruppo di lavoro e via dicendo.

 

Una volta definito il bersaglio inizia la attività di analisi. questa attività serve ad evidenziare tutti gli aspetti utili all’attacco e si svolge non solo in aree strettamente informatiche, ma a seconda del tipo di attacco possono comprendere anche analisi di tipo diverso, fino a vere e proprie ricognizioni fisiche, in quanto l’attacco stesso potrebbe richiedere attività dirette sul soggetto oggetto di attacco.

 

Possiamo quindi definire almeno die macro aree generali legate alla attività di analisi del bersaglio:

una attività di profilazione ed una di ricognizione.

Entrambe le attività possono usare tecniche comuni, ma la ricognizione è comunque una cosenguenza della esigenza di profilazione.

La profilazione richiede la costruzione di una scheda del bersaglio che contenga la maggior parte delle informazioni possibili utili allo svolgimento delle attività prevista, questa profilazione fa riferimento anche a caratteristiche “umane” del bersaglio quali struttura societaria, interfacce pubbliche, impiegati, competition, vicini, asset, distribuzione geografica…

I tools che si usano nella profilazione sono generalmente comuni attività di social engineering, talvolta phishing, sicuramente prevedono l’analisi di dati pubblici quali siti web, blog, forum sino ad arrivare talvolta a sopralluoghi fisici del sito.

Analogamente le attività di ricognizione, possono richiedere una serie di attività che portino alla definizione della topologia di rete del bersaglio, compresa la struttura dei routing, OS fingerprinting, l’analisi dei DNS e tutte quelle attività che possano ortare dati di definizione almeno della struttura esterna delle rete del bersaglio.

• —Social Engineering

• —Spear Phishing

• —DNS

• —External Network Topology

• —Port scanning

• —Service Discovery

• —Directory Harvesting

• —O.S. fingerprinting

• —Network Topology

• —Route Topology

• —Vulnerability analisys

• —…

Una volta definito il dettaglio del bersaglio è possibile passare al primo passo della aggressione: l’ingresso iniziale.

Sebbene nella convinzione comune l’ingresso iniziale sia l’attacco vero e proprio, questo passaggio ha invece uno scopo specifico che è quello di testare gli strumenti di attacco, definire il perimetro difensivo del bersaglio, trovare i punti di attacco disponibili e soprattutto iniziare a disegnare la topologia interna della rete bersaglio.

l’ingressoiniziale di solito si compone di sottoattività descritte nella slide, le più diffuse e comuni sono ovviamente:

• —Test vulnerabilità utilizzabili

• —Test riconoscimento attacchi e risposte

• —Definizione strategie multiple di copertura

• —Weaponization (prima infezione)

• —Exploitation

• —Topology

• —…

è interessante osservare come spesso le attività legate al primo ingresso sono comuni a molti tipi di attacchi, e spesso confusi col “rumore di fondo” degli eventi che accadano nelle nostre reti.

punti chiave del primo ingresso sono ovviamente la parte di utilizzo delle eventuali vulnerabilità scoperte per la prima infezione meglio chiamata, in letteratura anglofona, come weaponization che indica come si sia trasformato qualcosa in una arma.

Una volta effettuato il primo ingresso si dovrebbero avere indicazioni e strumenti sufficienti ad effettuare un livello di penetrazione più profondo che preveda il deployment di “qualcosa” che possa portare avanti le fasi successive dell’attacco.

Vale la pena di osservare che la fase di deployment può essere Remota, Fisdica o un mix di entrambe (Ibrida).

Un classico esempio di deployment fisico è l’introduzione di chiavette USB con payload malevoli, o l’attacco diretto ad una presa di rete di un device.

Si pensi ad esempio a quanto accaduto in Iran con l’affair SCADA, la fase di deployment era stata di tipo fisico con la “distribuzione” di chiavette USB infette in luoghi pubblici frequentati dagli operatori delle centrali nucleari.

A seguito del deployment vi è generalmente una fase di espansione i cui ci si attesta su alcune “teste di ponte” e si inizia ad analizzare quali siano i migliori punti di attacco, se non ancora noti, o ad attaccare bersagli diversi.

La fase di espansione può ancora contenere notevoli fasi di analisi ed esplorazione, ma essenzialmente si incentra con la creazione del network di attacco vero e proprio. Una parte di analisi fondamentale in fase di espansione è l’analisi dei processi del bersaglio. A seconda infatti di quello che che sono gli obiettivi l’analisi dei processi può dare indicazioni su come effettuare in concreto l’attacco.

Immaginiamo, ad esempio, che l’obiettivo sia di modificare codice o alcuni dati di un progetto. Queste modifiche avrebbero senso dopo eventuali fase di controllo e validazione, l’analisi del processo è quindi fondamentale per il successo della operazone.

Passi fondamentali della fase espansiva sono ovviamente l’infezione di hosts, movimenti laterali, azioni di copertura ed interferenza. In particolare la creazione di una o più reti di attacco e il test dei canali di comunicazione con l’esterno.

La fase successiva alla fase di espansione è, ovviamente, la fase di consolidamento.

In questa fase vi è la attivazione delle reti di attacco e la attivazione delle misure di copertura, questa fase può essere relativamente piccola in termini di azioni, ma può avere una notevole espansione temporale per rendere difficilmente riconoscibile e correlabile l’insieme delle attività

Alla fine finalmente possiamo finalizzare le nostre fini attività (ok ok sto giocando) in un attacco.

La fase di attacco vero e proprio non è descrivibile neanche in termini generici, perchè dipende dalla natura dei goals che si sono definiti in fase di definizione del bersaglio. tutto quello che possiamo dire che finalmente va a frutto il lavoro svolto in precedenza.

Alla fine della attività di attacco ci sono generalmente quelle di copertura, che servono a nascondere le tracce e le prove di quanto successo.

Ancora una volta vale la pena di stressare che gli APT hanno una fine, persistent non significa che vanno avanti in maniera illimitata. la fine dell’attacco generalmente porta alla cancellazione o alterazione  delle eventuali prove che possano ricondurre all’attaccante.

Una volta descritto il processo relativo ad un APT possiamo chiederci dove possiamo intervenire. a seconda della fase di un APT possiamo fare delle considerazioni generiche:

fase1: definizione bersaglio.

Questa fase non è rilevabile in quanto implica solo un uso marginale e non necessariamente illegale di strumenti di raccolta delle informazioni, ad esempio si pensi ad una analisi osint.

fase2: Analisi bersaglio

questa fase è parzialmente rilevabile, ma difficilmente associabile ad un APT o un attacco specifico. Viene di solito coperta ne “rumore di fondo” che gira attorno alle nostre reti.

fase3: primo ingresso

Le attività in questa fase sono rilevabili (Early External Detection) come attività esterne. Possono essere associate ad un attacco, ma difficilmente ad un APT l’eventuale blocco di questa fase è, se si tratta di un vero APT, solo apparente, perchè l’essere “scoperto” serve a testare la qualità dei sistemi difensivi e comunque una fase di primo ingresso in termini APT prevede una quantità notevole di tentativi diversi, di cui alcuni presumibilmente andranno a segno.

fase4: Deployment

Rilevabile (External Detection), questa è una delle fase critiche di un APT perchè è rilevabile, associabile ad un attacco esterno e, in presenza di una analisi storica degli eventi (ad esempio utilizzando correlazioni SIEM con una certa espansione temporale) può essere identificata come componente di un APT facendo alzare di conseguenza il livello di attenzione.

fase5: Espansione

Rilevabile (Early Internal Detection), in termini di rilevamento questa fase di attacco è ancora più critica della precedente in quanto si agisce già in maniera pesante all’interno del network target.

Va anche però osservato che le fasi interne hanno il vantaggio di vivere in aree dove il livello di attenzione è generalmente più basso, come a dire una volta entrati il più è fatto perchè si tende generalmente a concentrare le difese a livello perimetrale.

fase6: Consolidamento

Rilevabile (Internal Detection), per la fase di consolidamento valgono considerazioni analoghe al punto 6, con la considerazione che in fase di consolidamento vi sono, probabilmente, piu reti di attacco che si possono attivare con tempistiche diverse, il rilevamento quindi non necessariamente significa l’aver bloccato l’attacco. Come anche nelle fasi precedenti si ricordi che possono esserci attività di disturbo o decoy che servono a distrarre le difese.

fase7: Sviluppo attacco

Rilevabile (Late Internal Detection), la considerazione base da fare è che in questa fase siamo già in presenza di un attacco conclamato e quindi le attività da svolgere sono di contenimento danni.

fase8: copertura

Rilevabile (Post Mortem) tutto ciò che avviene dopo la  fase di attacco è una rilevazione di tipo post mortem, in qunato l’attacco oramai è andato in porto.

fase9: …

comunicazione esterna, ci avvertono che è avvenuto qualcosa

Cosa possiamo fare contro gli APT? in realtà molto poco, e molto.

Lo strumento più efficace contro un APT è la messa in piedi di una serie di processi coordinati di sicurezza, in cui tecnologie e processi aziendali siano disegnato con la sicurezza in mente.

come suggerimenti generali, validi non solo in ambito APT ma in generale in ambito sicurezza

1. —Complicare l’accesso iniziale (Firewall, Sandbox, Antimalware, gestione DNS e DHCP, IPS …)

2. —Monitorare constantemente le risorse (SIEM deployment, Vulnerability assessment, …)

3. —Ridurre il rischio di escalation dei privilegi in caso di compromissione di un account (NAC, IAC, DLP, …)

4. —Rilevare precocemente account compromessi e attività sospette (SOC, NOC…)

5. —Raccogliere informazioni utili a un’indagine forense, per poter determinare quali danni si sono verificati, quando e a opera di chi

una particolare raccomandazione è di tenere bene a mente il èpunto 5, solo una indagine forenze può darci da un lato gli strumenti legali per rifarci contro l’eventuale colpevole e le informazioni corrette per l’implementazione di misure correttive.

infine è importante ricordare che:

—Gli APT sono difficili da individuare. Secondo il Verizon 2012 Data Breach  Investigations Report, il 92% di tutte le organizzazioni e il 49% delle grandi organizzazioni è venuta a conoscenza di una violazione della sicurezza perché informata da un soggetto esterno.

un po di reference:

—Advanced volatile threat

—https://www.academia.edu/6309905/Advanced_Persistent_Threat_-_APT

—Anatomy of an Advanced Persistent Threat (APT)”. Dell SecureWorks. Retrieved 2012-05-21.

—Are you being targeted by an Advanced Persistent Threat?”. Command Five Pty Ltd. Retrieved 2011-03-31.

—Search for malicious files”. Malicious File Hunter. Retrieved 2014-10-10.

—“The changing threat environment …”. Command Five Pty Ltd. Retrieved 2011-03-31.

—Eric M. Hutchins, Michael J. Clopperty, Rohan M. Amin, Ph.D. “Intelligence-Driven Computer Network Defense Informed by Analysis of Adversary Campaigns and Intrusion Kill Chains”. Lockheed Martin Corporation Abstract. Retrieved March 13, 2013.

—Assessing Outbound Traffic to Uncover Advanced Persistent Threat”. SANS Technology Institute. Retrieved 2013-04-14.

—Introducing Forrester’s Cyber Threat Intelligence Research”. Forrester Research. Retrieved 2014-04-14.

—Olavsrud, Thor. “Targeted Attacks Increased, Became More Diverse in 2011”. PCWorld.

—An Evolving Crisis”. BusinessWeek. April 10, 2008. Archived from the original on 10 January 2010. Retrieved 2010-01-20.

—The New E-spionage Threat”. BusinessWeek. April 10, 2008. Archived from the original on 18 April 2011. Retrieved 2011-03-19.

—Google Under Attack: The High Cost of Doing Business in China”. Der Spiegel. 2010-01-19. Archived from the original on 21 January 2010. Retrieved 2010-01-20.

—Under Cyberthreat: Defense Contractors”. BusinessWeek. July 6, 2009. Archivedfrom the original on 11 January 2010. Retrieved 2010-01-20.

—Understanding the Advanced Persistent Threat”. Tom Parker. February 4, 2010. Retrieved 2010-02-04.

—Advanced Persistent Threat (or Informationized Force Operations)”. Usenix, Michael K. Daly. November 4, 2009. Retrieved 2009-11-04.

—Ingerman, Bret. “Top-Ten IT Issues, 2011”. Educause Review.

—Bodmer, Kilger, Carpenter, & Jones (2012). Reverse Deception: Organized Cyber Threat Counter-Exploitation. New York: McGraw-Hill Osborne Media. ISBN 0-07-177249-9, ISBN 978-0-07-177249-5

—Advanced Persistent Threats: Higher Education Security Risks”. Dell SecureWorks. Retrieved 2012-09-15.

—APT1: Exposing One of China’s Cyber Espionage Units”. Mandiant. 2013.

—China says U.S. hacking accusations lack technical proof”. Reuters. 2013.

—What’s an APT? A Brief Definition”. Damballa. January 20, 2010. Archived from the original on 11 February 2010. Retrieved 2010-01-20.

grazie 🙂

Related articles

• Use Data Analytics to Combat Advanced Persistent Threats
• Is Sandboxing technology the answer?
• On the Air with General Dynamics: Defend Yourself Against Advanced Threats
• Russian-based cyber spies going after military, intelligence targets
• Malware attacks almost double in EMEA – FireEye report
• Operation DeathClick
• ThreatTrack Security Joins Industry Peers to Disrupt APT Axiom
• Axiom – A Chinese APT
• Symantec and Security Vendors Take Action against Hidden Lynx Malware
• Chinese Hackers Target Law Firms