Article

Che cos’è il Security Service Edge (SSE)?

L’adozione massiva dei servizi cloud e l’utilizzo sempre più spinto del modello di lavoro ibrido hanno  declinato in un nuovo modo tre importanti sfide del mondo della cybersecurity: visibilità, controllo e trust.

Le moderne architetture, ibride e multi-cloud, introducono la necessità di gestire gli accessi e l’utilizzo delle risorse secondo un approccio dinamico e identity-centric.

Questi principi sono alla base delle soluzioni di sicurezza Security Service Edge (SSE) che presidiano gli accessi e l’utilizzo dei servizi cloud, del web e delle applicazioni private, centralizzandone e semplificandone la gestione.

L’adozione massiva del cloud

L’adozione dei servizi cloud ha subito un forte incremento negli ultimi anni. Oggi, molte aziende adottano molteplici servizi, affidandosi a Cloud Service Provider differenti.  Questo ha introdotto una certa complessità derivante non solo dal numero di servizi utilizzati, ma anche dalla loro eterogeneità.

Per avere il polso della situazione basta pensare a quante applicazioni di tipo SaaS ognuno di noi utilizza nella propria attività lavorativa. Senza contare che esiste un ampio “sommerso”, di applicazioni sulle quali non si ha visibilità.

Quali sono i problemi che ne derivano? Esistono diverse criticità:

• Le applicazioni sono numerose e una parte di esse è “unsanctioned”, ovvero non gestita/regolamentata dal reparto IT. Questo, potenzialmente, aumenta l’esposizione al rischio dell’azienda.
• Alcuni dei servizi utilizzati potrebbero non aderire a specifiche normative. Questo è un problema in ottica di compliance, se si pensa che un servizio SaaS, ove utilizzato per gestire informazioni e processi aziendali, è a tutti gli effetti un fornitore esterno.

• Molti dei servizi utilizzati sono ridondanti ed ognuno di essi ha le proprie regole di gestione. Questo conduce ad una gestione frammentata di questi sistemi e incrementa la difficoltà di poter applicare processi di governance efficaci.
• La facilità di utilizzo di alcuni servizi, in particolare di storage, affiancata alla mancata applicazione di regole, introduce delle criticità importanti legate alla dispersione dei dati.

Il modello di lavoro ibrido

Il nostro modo di lavorare è cambiato. Molte aziende sposano la politica del “remote first”. Ognuno di noi ha potenzialmente la possibilità di lavorare da qualsiasi luogo e con qualsiasi dispositivo.

Il modello ibrido, derivato dalla digital transformation, dai modelli di Bring Your Own Device (BYOD) e accelerato dalla pandemia, è ormai una realtà di fatto e deve essere gestito in maniera corretta per evitare inefficienze e soddisfare il principio di zero-trust, sul quale le moderne architetture ed i processi a supporto devono fondarsi.

Questo porta alla necessità di costruire un nuovo paradigma che ha come perno centrale l’identità. La modalità di accesso alle risorse tuttavia non può essere più basata su fattori statici (sei dentro/fuori dalla rete aziendale), ma deve essere definito in maniera dinamica, sulla base di diversi parametri legati al contesto del richiedente.

Security challenges

In un’architettura ibrida e multi-cloud, il modello di accesso “tradizionale”, dove tutto il traffico è instradato da un unico punto centrale (il data center), non è più sostenibile. Allo stesso tempo, la flessibilità richiesta dalle aziende per poter mantenere ed incrementare la propria produttività, non deve andare a discapito della sicurezza.

Le sfide principali sono tre:

• Visibilità: Per poter proteggere qualcosa, è indispensabile sapere cosa proteggere e qual è il grado di esposizione al rischio. E’ necessario quindi avere una mappatura completa dei servizi utilizzati, delle interazioni tra gli utenti e questi servizi e dei dati che fluiscono al loro interno.
• Controllo: Una volta ottenuta la visibilità, è fondamentale poter governare l’utilizzo di questi servizi. E’ quindi importante poter stabilire, in modo flessibile e granulare, chi può accedere ad un servizio e come può interagire con esso.
• Trust: Fattori statici come l’appartenenza o meno alla rete aziendale, non sono più sufficienti, da soli, a determinare un rapporto di trust. E’ necessario quindi che l’accesso e l’utilizzo delle risorse vengano implementati nel rispetto dei principi di Zero-Trust, che nel caso più semplice potrebbe tradursi nell’applicazione dei noti principi di least-priviledge e always-verify.

A queste tre sfide si affianca, in maniera trasversale, il rispetto della compliance normativa. La complessità delle architetture moderne deve comunque consentire una gestione efficace della compliance, permettendo alle aziende di estendere le verifiche e l’applicazione dei meccanismi di protezione più adeguati, anche al mondo cloud.

Il modello SASE

In questo contesto si colloca il Secure Access Service Edge (SASE), termine coniato per identificare un’architettura di sicurezza che supporta l’accesso e l’utilizzo dinamico delle risorse.

Le soluzioni SASE si fondano su tre principi fondamentali:

• Centralità dell’identità che accede o utilizza il servizio
• Valutazione continua del rischio, come parametro decisionale per determinare l’accesso, che tiene conto non solo dell’identità ma anche del suo contesto
• Modello as-a-service

Le architetture SASE hanno una duplice anima, una costituita da servizi di rete e l’altra da servizi di sicurezza. Il sottoinsieme di servizi di sicurezza del SASE è chiamato Security Service Edge (SSE).

Soluzioni di sicurezza SSE

Le soluzioni SSE sfruttano diverse tecnologie tra le quali Cloud Access Security Broker (CASB), Secure Web Gateway (SWG) e Zero-Trust Access Network (ZTNA), per offrire servizi di sicurezza a presidio dei servizi cloud, del web e delle applicazioni private.

Le capability di sicurezza sono diverse. Tra le principali troviamo:

• Discovery, che consente di rispondere a domande come: quali servizi cloud vengono utilizzati? Quali servizi vengono utilizzati ma non sono approvati dall’IT? Che livello di rischio hanno? Quali attività utente sono potenzialmente a rischio?
• Access Control, che permette di implementare regole per concedere, limitare o inibire l’accesso ai servizi e ai dati e di farlo a diversi livelli di granularità. Per esempio: impedire l’accesso ad una specifica categoria di SaaS, limitare le attività su un SaaS ad alcuni gruppi di utenti o in presenza di determinate condizioni, impedire azioni su particolari categorie di dato. Quest’ultima funzionalità è di particolare utilità in ottica di compliance.
• Data Security. Il dato può essere protetto sia quando è a riposo, sia quando è in uso. Il concetto di Data Security include in maniera intrinseca Data Discovery, Data Classification e Data Loss Prevention (DLP). E’ possibile quindi identificare specifiche categorie di dati, come I dati GDPR, PCI, dati confidenziali. E’ possibile monitorare l’utilizzo di questi dati e applicare delle regole di Data Right Management come ad esempio: cifratura, filigrana e mascheramento.

Infine, la possibilità di gestire i tre target – web, servizi SaaS e applicazioni private – da un unico strumento, consente di centralizzare l’applicazione delle regole, il monitoraggio e la governance, semplificandone e consolidandone la gestione.

Se vuoi approfondire la tematica, scrivici a info@radsec.it

by RAD Staff

10 Consigli per sviluppare applicazioni sicure

Costruire una applicazione software è già un compito complesso di per se. Costruire una applicazione software sicura complica la situazione notevolmente!
Ecco dieci consigli da tenere in mente per sviluppare un’applicazione robusta e sicura, proteggendola da attacchi di hacker e cybercriminali.

1.      Non fidarti mai

Ottenere un’applicazione sicura al 100% è un obiettivo ammirevole, ma irrealizzabile.

Ogni applicazione, indipendentemente dalla complessità o dalle tecnologie utilizzate, è vulnerabile ad attacchi informatici. Gli sviluppatori devono adottare tutte le misure di sicurezza possibili, ma ci saranno sempre falle di sicurezza che possono essere sfruttate. Anche i framework più testati e gli algoritmi più sicuri possono essere soggetti a vulnerabilità nascoste, quindi è importante NON FIDARSI MAI.
Se guidati da questo principio durante la progettazione e lo sviluppo, sarà più semplice riuscire a minimizzare i rischi dell’applicazione garantendo un alto livello di sicurezza.

2.       Pianifica il progetto in modo sicuro

Molto spesso, nella progettazione di un'applicazione, l'attenzione viene posta esclusivamente sugli aspetti funzionali o di performance.

Tuttavia, la pianificazione dell’architettura, la scelta delle tecnologie, delle librerie, dei linguaggi utilizzati va effettuata anche in ottica di sicurezza e va presa in considerazione nella primissima fase di design, in modo da evitare rallentamenti e aumento di costi derivanti da modifiche “in corso d’opera”.

Nella scelta delle componenti va tenuto conto che:

• Esistono linguaggi di programmazione intrinsecamente più sicuri di altri
• Librerie e framework vanno scelti accuratamente, preferendo componenti largamente utilizzati, testati e aggiornati con frequenza
• La scelta dell’architettura e dell’organizzazione delle componenti deve essere orientata all’utilizzo delle tecniche e degli algoritmi di sicurezza più avanzati

3.      Effettua il testing in maniera estensiva

In qualsiasi ciclo di sviluppo, la fase di testing è importante e non va assolutamente sottovalutata.

Il testing è necessario per identificare e correggere tutte le problematiche delle applicazioni prima che queste vengano rilasciate in produzione, in modo da proteggere adeguatamente la informazioni e garantire la continuità operativa.

L’analisi statica e dinamica del codice, il fuzzing, la code review e il penetration testing, sono esempi dei più comuni metodi di testing delle applicazioni nei diversi momenti del loro ciclo di vita. Sfruttare queste metodologie è la chiave vincente per essere confidenti che il proprio prodotto risulti sicuro nelle più disparate condizioni.

4.      Automatizza i processi ripetitivi

I processi di sviluppo ripetitivi nascondono delle insidie pericolose.

Può capitare, per esempio, che per negligenza o per disattenzione alcuni passaggi vengano saltati o che alcuni step vengano eseguiti frettolosamente.

È consigliabile dunque, ove possibile, evitare che attività ripetitive vengano eseguite manualmente. Tutto quello che può essere automatizzato, va automatizzato. Dal testing alla distribuzione, tutto deve essere reso semplice e immediato.

Investire nell’automazione comporta sicuramente un effort, ma a lungo termine porta vantaggi significativi e permette di mantenere sotto controllo tutti i processi legati al progetto, evidenziando in modo efficace tutte le criticità. Inoltre, semplifica la vita agli sviluppatori, che possono concentrarsi su attività più impegnative.

5.      Aggiorna il software

I sistemi operativi, i framework e le librerie di terze parti sono, anch’esse, soggette a vulnerabilità.

Aggiornare un’applicazione è una operazione necessaria, ma molte volte viene tralasciata o sottovalutata. A volte, questa operazione può essere tediosa, anche a causa di eventuali problemi di compatibilità che emergono e che richiedono la modifica o la riscrittura di parti di codice. In questo caso, è buona norma, eseguire le operazioni di aggiornamento frequentemente anche in modo da ridurne la complessità.

Aggiornare tutti i pacchetti e le dipendenze di un’applicazione richiede tempo e dedizione. Tuttavia, l’esecuzione periodica di questa attività rappresenta un tassello fondamentale nella prevenzione degli attacchi informatici, poichè riduce notevolmente la superficie d’attacco.

6.      Utilizza la cifratura in maniera corretta

La protezione del dato è un aspetto fondamentale e spesso è legato al rispetto di normative e legislazioni.

Il dato deve essere opportunamente protetto in qualunque fase della sua conservazione, elaborazione e utilizzo.

Alcuni meccanismi di protezione come la cifratura, consentono, anche in caso di leak, di limitare I danni, rendendo il dato inutilizzabile esternamente. In questo caso è importante:

• Non sviluppare algoritmi di cifratura in proprio, ma basarsi sempre su algoritmi testati e noti
• Verificare sempre che le chiavi di cifratura siano gestite in modo corretto
• Studiare a fondo le librerie di crittografia scelte per evitare di configurarle in modo errato
• Utilizzare protocolli cifrati per la trasmissione (es. HTTPS)

7.      Utilizza i log in modo estensivo

L’importanza dei log viene spesso sottovalutata.

Il logging non solo è utile per aiutare l’analisi dei malfunzionamenti dell’applicazione da parte degli sviluppatori ma è necessario per un insieme di attività di cyber security. Ad esempio, risulta essenziale per:

• Auditing delle attività degli utenti
• Rivelazione delle intrusioni
• Analisi forense

I log devono essere accurati, esaustivi e frequenti. Devono riportare le informazioni necessarie per poter ricostruire esattamente lo stato del sistema, ma allo stesso tempo non devono esporre informazioni sensibili quali dati privati, credenziali di autenticazione e informazioni legate al debug.

8.      Applica il principio del “Least Privilege”

Ogni componente può esporre a rischi di compromissione. Una volta compromesso, le azioni che un attaccante può portare avanti dipendono anche dai privilegi del componente stesso.

Per questo, ogni componente deve avere assegnato il set minimo di privilegi necessari al suo funzionamento, nulla in più.  E’ buona prassi quindi verificare che ogni componente non abbia mai più privilegi o più capacità di quelle necessarie per poter eseguire i suoi task.

Questo passaggio deve avvenire soprattutto nelle fasi di refactoring del codice, dove le componenti possono cambiare in parte le loro funzionalità, e potrebbero essere dimenticati dei privilegi per delle azioni che quel componente non deve più compiere.

9.      Non abusare delle librerie esterne

È impossibile sviluppare del codice senza importare librerie.

Tuttavia, è bene essere moderati, e non importare enormi librerie che nel codice devono svolgere solo un semplice task. Ogni libreria intrinsecamente contiene delle vulnerabilità. Se il codice non utilizza nemmeno quelle componenti, si rischia di aggiungere delle potenziali criticità all’applicazione senza ottenere un reale vantaggio.

E’ opportuno quindi analizzare e pianificare con criterio quali librerie di terze parti sono necessarie per il funzionamento dell’applicazione, in modo da valutare se può essere preferibile sviluppare delle funzioni autonomamente.

10. Adotta un processo di sviluppo sicuro

I punti precedenti non rappresentano una lista esaustiva. Esistono numerosi altri aspetti da considerare.

Al giorno d’oggi, lo sviluppo di un’applicazione non può prescindere dalla sua messa in sicurezza.

E’ controproducente, in termini di costi ed effort, improvvisare. E’ buona norma invece, adottare un processo di sviluppo di sicuro, che tenga conto dei diversi aspetti di sicurezza, in tutte le fasi: dal design all’implementazione, dal testing all’esecuzione.

A prescindere dalla grandezza del team o dell’applicazione stessa, è utile strutturare delle procedure di verifica e affidarsi all’esperienza e alle best practice di settore.

Se vuoi approfondire la tematica, scrivici a info@radsec.it

by RAD Staff

Next-Gen Threat Detection: un approccio multicentrico

Negli ultimi anni il panorama della sicurezza difensiva si è arricchito di strumenti innovativi che stanno consentendo ad un numero crescente di realtà di godere dei benefici derivanti dall’utilizzo di algoritmi basati sul ML, analisi comportamentale, e interconnessione tramite servizi cloud.

L’integrazione di strumenti di nuova generazione e l’utilizzo di un approccio multicentrico consentono di migliorare l’efficacia della propria strategia di difesa, senza stravolgere totalmente l’architettura pre-esistente, sfruttando a proprio vantaggio le sinergie tra le strumentazioni di nuova concezione e quelle maggiormente consolidate.

Dalla tradizionale architettura SIEM-centrica…

Tradizionalmente, il perno delle architetture di monitoraggio e rilevamento delle minacce è costituito dal SIEM (Security Information and Event Management), uno strumento di raccolta e gestione centralizzata delle informazioni e degli eventi.

In questa architettura di riferimento gli eventi rilevanti per la sicurezza vengono collezionati presso tutti i nodi della rete (server, workstations, firewalls, ..) per poi essere trasmessi direttamente al SIEM centrale che si occupa della loro registrazione e conservazione.

Il SIEM fornisce quindi agli operatori una serie di funzionalità avanzate per l’elaborazione dei log, quali la ricerca puntuale dei dati, la normalizzazione dei flussi similari, la correlazione tra sorgenti differenti e l’arricchimento con dati da fonti esterne (es. intelligence). È prevista inoltre l’allarmistica automatica e la possibilità di progettare viste avanzate tramite apposite dashboard.

Nella concezione classica delle architetture di monitoraggio quindi, il cuore del motore di rilevamento è costituito dal SIEM, mentre presso i nodi decentrati avvengono, per la gran parte, attività passive di collezionamento o, al più, filtraggio/blocco automatico in base a semplici regole predeterminate (es. antivirus e dispositivi di rete di vecchia concezione)

…Agli strumenti di monitoraggio “Next-Gen”

Più recentemente si è assistito a una drastica evoluzione del paradigma SIEM-centrico, grazie all’avvento di tecnologie evolute quali:

-              EDR (Endpoint Detection and Response), che permettono di superare le tradizionali soluzioni antivirus sugli endpoint, affiancando alle regole di filtraggio statiche (Indicator of Compromise) tecniche di analisi più sofisticate e proattive, basate sull’analisi e il confronto dei comportamenti anomali degli utenti (Indicator Of Attacks). Gli EDR consentono inoltre di definire con un elevato grado di personalizzazione, azioni di risposta automatiche per reagire tempestivamente alle minacce, o di intervenire manualmente da remoto direttamente sul singolo endpoint.

-              XDR (eXtended Detection and Response), che estendono ulteriormente il concetto di EDR, permettendo il monitoraggio e l’intervento di mitigazione automatica a copertura di un perimetro ancora più ampio rispetto ai soli endpoint, tramite l’integrazione di dispositivi eterogenei (apparati di rete, controller di dominio, gateway di posta,...)

-              Next Generation Firewall/Proxy, che potenziano i tradizionali dispositivi di monitoraggio del traffico di rete perimetrale, basati su regole statiche, con funzionalità evolute, quali la capacità di rilevare anomalie rispetto al traffico abituale dei singoli utenti/gruppi di lavoro/applicazioni, e la categorizzazione automatica del traffico malevolo sulla base di fonti esterne di Intelligence (proprietarie o open-source)

-              CASB (Cloud access security broker), servizi di monitoraggio situati tra gli utenti e le applicazioni dei perimetri Cloud, che permettono l’applicazione automatica di policy di sicurezza personalizzabili, il rilevamento di malware e anomalie comportamentali (es. data exfiltration) nonché l’applicazione di politiche di data protection.

-              SOAR (Security Orchestration, Automation and Response), strumenti evoluti che permettono di disegnare e attuare risposte automatiche complesse a fronte della ricezione di eventi o combinazioni di eventi con caratteristiche predefinite, nonché di implementare automazioni coinvolgendo diversi tool di sicurezza e non. In questo modo è possibile alleggerire notevolmente il carico delle azioni di routine che gravano solitamente sugli operatori umani, migliorandone efficienza e tempi di reazione.

I vantaggi di un approccio multicentrico

Le tecnologie “Next-Gen” sono accumunate dalla capacità di poter applicare le metodologie di monitoraggio e di intervento più innovative e performanti direttamente presso i sistemi periferici.

In questo modo, combinando le differenti strumentazioni dislocate su più punti in un approccio multicentrico, è possibile migliorare sensibilmente l’efficacia dell’intera strategia di prevenzione, realizzando compiutamente la best practice della Defense-In-Depth.

La piattaforma SIEM già esistente può essere pienamente sfruttata per progettare e realizzare quelle logiche di monitoraggio che richiedono un livello di correlazione più spinto, impossibile da attuare presso le singole fonti, massimizzando così l’utilità della piattaforma.

Il SIEM può così agire da centralizzatore per i vari allarmi generati dai diversi tool di sicurezza, fornendo agli analisti un set informativo ricco e preciso sulle minacce in corso.

Allo stesso tempo, il filtraggio evoluto effettuato già a livello dei singoli nodi è in grado di ridurre notevolmente il livello di rumore e il numero di falsi positivi che contraddistinguono da sempre le architetture tradizionali, riducendo l’impatto della temuta Alarm Fatigue a carico degli operatori fisici.

Un esempio concreto

I protocolli applicativi cosiddetti ‘standard’, comunemente utilizzati per scopi legittimi, sono potenzialmente adatti a celare traffico malevolo (ad esempio durante attacchi di data exfiltration e comunicazioni C2).

Questa tipologia di traffico risulta tradizionalmente ostica da monitorare esclusivamente mediante sistemi centralizzati a causa dell’enorme quantità di eventi “innocui” costantemente generata dalle applicazioni durante le operazioni di routine, e che ai fini del monitoraggio costituiscono una quantità notevole di rumore di fondo.

Per consentire un rilevamento tempestivo ed efficace di eventuali abusi, diventa dunque fondamentale poter disporre di strumenti in grado di filtrare, intervenire e bloccare le comunicazioni sospette direttamente “in loco”, ovvero sui sistemi periferici.

Un Next-Gen Proxy, ad esempio, è in grado di rilevare e bloccare richieste indirizzate a domini inconsueti o notoriamente utilizzati in campagne di attacco. Il proxy, in questo caso, svolge un duplice compito: da un lato filtra il traffico non di interesse, dall’altro consente di implementare un primo strato di sicurezza attiva.

In un secondo livello, il SIEM può poi raccogliere i dati generati presso questo primo layer difensivo per consentire analisi più complesse, correlando tali dati su scala più ampia con eventi provenienti da altre sorgenti.

Questo permette di contrastare attacchi più sofisticati come, ad esempio, una campagna di phishing rilevata correlando le connessioni http bloccate dal proxy verso domini sospetti con gli eventi registrati nello stesso arco temporale dal mail gateway.

L’offerta RAD

La pluriennale esperienza maturata all’interno del competence center di Cyber Security Monitoring di RAD, testimonia che nella grande maggioranza dei casi è possibile aggiornare e potenziare i sistemi di monitoraggio aziendali conservando gran parte dell’architettura pre-esistente.

Tramite il nostro servizio di consulenza personalizzata è possibile beneficiare del livello di protezione offerto dalle tecnologie più innovative integrandole direttamente all’interno dell’attuale ecosistema, valorizzando nel migliore dei modi investimenti passati e futuri e permettendo ai talenti umani di focalizzarsi meno su attività di routine e sempre più su attività di valore.

Se vuoi scoprirne di più, scrivici a info@radsec.it o visita il nostro sito www.radsec.it.

by RAD Staff

I benefici del SOAR

All’interno di un SOC è ormai sempre più frequente trovare un SOAR o essere in procinto di vederne l’adozione. Esistono infatti dei vantaggi e delle modalità nel suo utilizzo che, se sfruttati a dovere, possono portare un beneficio importante alle dinamiche del SOC.

Incident Management Centralizzato

Avere a disposizione un SIEM consente già di accentrare in un unico punto le notifiche provenienti dalle varie tecnologie di cui un SOC si avvale, come per esempio l’EDR, il tool di Mail Security, la sonda Network, e altri.

L’adozione di un SOAR offre le stesse possibilità, ma in una veste nuova e potenziata. Nello stesso strumento è infatti possibile integrare anche i workflow operativi del SOC, riuscendo ad ottenere un connubio tra attività che restano manuali ed altre che vengono automatizzate. A seconda dei livelli di maturità nell’utilizzo del SOAR, questo grado di automazione può variare e può essere potenziato nel tempo.

L’integrazione e l’adeguata configurazione delle varie tecnologie nel SOAR permettono ad esempio di:

• Accorpare allarmi in casi singoli, correlando fra loro segnalazioni simili, con una logica di raggruppamento personalizzabile e automatizzabile. Questo riduce il numero di notifiche da lavorare e permette all’analista di avere una visione più ampia all’interno del singolo caso.
• Normalizzare gli eventi su un modello uniforme, in modo da avere dati ricercabili in maniera semplice e univoca, indipendentemente dalle tecnologie sottostanti.
• Sviluppare logiche di riduzione del rumore ed effettuare filtering avanzato avente visibilità cross-prodotto.
• Effettuare Business Intelligence su metriche e KPI, avendo visibilità sia delle performance dei prodotti utilizzati, sia degli analisti che ne lavorano le segnalazioni. Un’adeguata comprensione di come gli analisti interagiscono con il SOAR e le relative tecnologie permette di aumentare la maturità del SOC.

Tutto questo si traduce in una maggiore efficienza nella lavorazione delle segnalazioni da parte degli analisti, che hanno un solo prodotto da dover monitorare attivamente con dei casi cross-tecnologici basati sulla minaccia effettiva.

Automatizzare la fase di Triage

Le operazioni iniziali, solitamente eseguite da analisti di primo livello, sono spesso molto ripetitive e meccaniche. Effettuare questa fase di Triage attraverso le funzionalità di automazione del SOAR ha un triplice vantaggio:

• Velocizzare e ridurre il margine di errore di molte di queste operazioni, come ad esempio:
  • Il triage degli IOC su fonti di Intelligence come VirusTotal, MISP, o altre fonti.
  • Il download e la detonazione di file o di URL sospetti in una o più sandbox.
  • La raccolta di informazioni circa asset, user o IP coinvolti dalle inventory.

Il tutto grazie all’integrazione con le varie tecnologie/sorgenti e la relativa possibilità di sfruttarne le funzionalità attraverso azioni automatiche.

• Effettuare il match con casi passati già risolti, i cui risultati della lavorazione possono venire integrati come ulteriori evidenze del caso in esame. Una buona configurazione del SOAR permette di ricercare dei casi simili, magari fornendo uno score di similitudine in base a quanti elementi i due casi condividono, come ad esempio la presenza della stessa minaccia/pattern d’attacco, stesso host o stesso user, o altro.
• Collezionare in modo ordinato ed esaustivo tutte le evidenze, siano esse raccolte in modo automatico o aggiunte manualmente dagli analisti. Link a pagine esterne possono consentire di approfondire velocemente le analisi di maggiore interesse.

Prendere decisioni in maniera automatica: l’approccio RAD

Un SOAR offre la possibilità di ideare dei workflow che permettono di prendere decisioni automatiche sulla risoluzione di un caso, sia esso malevolo oppure falso positivo.

Stabilire questo in maniera automatica è un’operazione critica ed è possibile farlo solo quando si è ragionevolmente sicuri, lasciando invece le altre casistiche all’approfondimento e alla decisione manuale.

Per massimizzare la precisione della decisione e migliorare la gestione del caso, RAD ha adottato un approccio avanzato basato su alcune linee guida:

• Anziché definire un caso “bianco” o “nero”, definirlo come una “scala di grigi”. Nello specifico, è possibile definire una metrica di affidabilità con cui si rappresenta il livello di pericolosità di un caso.

A questa metrica partecipano, fra gli altri, i seguenti elementi, ciascuno col relativo peso:

• La tipologia di allarmi o detection che compongono il caso, tenendo in considerazione l’affidabilità della tecnologia e/o la regola in questione. Ad esempio, una detection EDR basata su signature malevola ha una affidabilità maggiore rispetto ad una detection basata su regole Machine Learning.
• Gli esiti del triage effettuati nella fase precedente.
• Il fattore storico, che risponde alla domanda “qual è stato l’esito dei casi precedenti simili a questo?”.
• Il fattore temporale e/o geografico, con pesi maggiori a operazioni fatte in orari e giorni considerati non usuali oppure da paesi non previsti.

• In alcune casistiche viene previsto il coinvolgimento diretto dell’utente finale, che può fornire un riscontro in tempi brevi relativamente al riconoscimento delle attività sospette, attraverso il canale chat oppure mail.
• Dato che non è possibile assumere la decisione come infallibile, viene prevista la possibilità di andare a ritroso nelle decisioni. Questo si traduce nel prevedere dei playbook con opzione “undo”, che lasciano la possibilità di azionare manualmente, per un certo lasso di tempo, un workflow di annullamento automatico di tutte le azioni attuate fino a quel punto.

Automatizzare la fase di Response e Notification

Dopo aver stabilito l’esito di un caso è possibile predisporre degli automatismi per effettuare le azioni di contenimento e/o remediation direttamente sui sistemi coinvolti. Il vantaggio in questo caso è che l’analista può utilizzare un’unica interfaccia, quella del SOAR, per attuare azioni su più tecnologie.

Non solo: è anche possibile sfruttare tutte le informazioni già contenute in un caso per generare in maniera automatica un feedback di notifica fine lavorazione, per uso interno o da inoltrare a terzi interessati.
Informazioni quali la priorità, gli elementi coinvolti (asset, user, IP, …) o i dati provenienti da arricchimenti esterni sono già presenti sul SOAR e sono quindi integrabili automaticamente nel template di notifica. L’analista deve dedicarsi solo all’eventuale stesura di un testo di dettaglio sul caso e sulle azioni da intraprendere.

Come ultimo step di notifica, nel caso l’utente finale abbia accesso direttamente all’interfaccia del SOAR, può analizzare il report con la lavorazione del caso avendo visibilità su tutte le azioni eseguite e le relative note/segnalazioni. Viceversa, un’automazione potrebbe procedere all’invio del report via e-mail (o altri canali) selezionando il destinatario corretto in base ai dati di contesto presenti nel caso, minimizzando il rischio di errori manuali.

RAD ha maturato una grande esperienza sulla tecnologia SOAR e sulla sua integrazione nell’ecosistema delle tecnologie di sicurezza. Se vuoi approfondire la tematica scrivici a info@radsec.it o scopri il nostro Competence center di Incident Response 

by RAD Staff

Breve guida al Threat Modeling per ICS

Affrontare il tema “security” in ambito industriale non è mai semplice.

Si tratta di lavorare con infrastrutture spesso critiche ed è necessario porre molta attenzione a non impattare l’andamento delle operazioni.

L’attività di Threat Modeling può tornare molto utile in questo contesto, ancor più che in ambito IT, evidenziando le minacce più pericolose e le contromisure più critiche da adottare.

I sistemi di controllo industriale

Si tratta di sistemi di vario genere, come SCADA, DCS e PLC, che permettono il monitoraggio e la variazione dei parametri operativi dei componenti di campo (e.g. attuatori, turbine, sensori).

Vengono identificati con l’acronimo inglese ICS, Industrial Control System, e sono alla base della moderna industria.

Storicamente, nella realizzazione di architetture industriali si è favorita la netta separazione tra i sistemi ICS e i sistemi IT, collocando i primi all’interno di ambienti “air gapped” isolati.

Tuttavia, negli ultimi 20 anni, la diffusione di dispositivi più “smart”, dell’IIoT (Industrial Internet of Things), in combinazione con la crescente necessità delle aziende di monitorare ed accedere ai sistemi da remoto, ha fatto sì che il mondo IT permeasse sempre più all’interno di quello ICS.

ICS e Cybersecurity

La fusione tra ambiente industriale e tecnologie informatiche ha permesso alle aziende di adottare soluzioni più economiche e di aumentare la propria competitività sul mercato, ma con l’utilizzo di soluzioni consumer e protocolli standard più accessibili, i sistemi ICS sono diventati più esposti all’ambiente esterno.

È importante comprendere che, quando si parla di sicurezza in ambito ICS, i criteri di valutazione sono ben diversi da quelli IT. L’accento non va più posto su confidenzialità, integrità e disponibilità (paradigma CIA) ma su sicurezza fisica di apparati e persone, affidabilità e disponibilità (paradigma SRA).

PERA

Acronimo di Purdue Enterprise Reference Architecture, anche noto come modello Purdue, PERA è un modello di riferimento per architetture enterprise sviluppato negli anni ‘90.

Il modello è costituito da sei livelli, numerati da 0 a 5, ognuno dei quali è costituito da uno specifico insieme di apparati e tecnologie. Al livello più basso si trovano tutti i dispositivi di campo, come sensori, attuatori e valvole. Al livello più alto stanno invece tutte le tecnologie a corredo del business, come Active Directory, e-mail e software CRM.

Tra il terzo e il quarto livello si trova il confine tra il mondo dei sistemi ICS e quello del mondo IT. Questo punto è stato a lungo trattato come una sorta di DMZ, in grado di proteggere in un ambiente “air gapped” gli apparati più critici.

È importante notare che il modello Purdue non è stato pensato per la cybersecurity e che il suo scopo principale è esclusivamente quello di aiutare nella segmentazione delle reti per favorire l’integrazione tra ambienti IT e industriali.

Nonostante questa limitazione, PERA è ancora ampiamente adottato, ed è stato usato come punto di partenza per sviluppare nuovi modelli più focalizzati sulla sicurezza, come ad esempio il SANS ICS410 Reference Model. Resta inoltre un ottimo supporto durante le attività di threat modeling.

Threat modeling

Con il termine threat modeling si intende il processo di analisi delle potenziali minacce. Questo si effettua attraverso l’identificazione dei vettori di attacco sfruttabili da un attore malevolo, e degli obiettivi che plausibilmente prenderebbe di mira.

Se fatto correttamente, il threat modeling permette di:

• produrre dati misurabili, sul tipo di minacce e sulle probabilità di ognuna di trasformarsi in eventi avversi;
• rispettare requisiti regolatori, quando espressamente richiesto, o facilitarne l’adeguamento rendendo più semplici le operazioni di auditing;
• risparmiare denaro, permettendo di identificare per tempo le possibili falle di sicurezza, quando non è ancora troppo oneroso correggerle.

Come si effettua il threat modeling

Generalmente, il processo di threat modeling è suddivisibile in tre steps successivi, ciascuno dei quali prende in input i risultati del precedente.

1.      Modellazione dell’architettura e dei processi

Consiste nell’identificazione di tutti gli assets, dei punti d’ingresso e dei livelli d’accesso che permettono il normale funzionamento di un ambiente. PERA, il modello di cui abbiamo accennato prima, torna molto utile a questo proposito in campo industriale.

Genera come output una mappa dei flussi di dati, nota anche come Data-flow Diagram o DFD.

2.      Classificazione delle minacce

Si appoggia alla mappa dei flussi prodotta durante lo step della modellazione per aiutare a identificare, categorizzare e valutare le minacce.

Nel corso degli anni, in ambito IT sono stati sviluppati diversi modelli per rendere più semplice questo passaggio. Un esempio è dato dai metodi STRIDE e DREAD.

STRIDE (Spoofing, Tampering, Repudiation, Information Disclosure, Denial of Service, Elevation of privilege) è utilizzato per classificare le minacce e assegnarle ad una categoria. Nel caso ICS, ricordando il paradigma SRA, è possibile aggiungere due nuove classi di minacce al modello: Physical DoS e Physical harm, per cui si parlerà di STRIDEPP.

DREAD (Damage, Reproducibility, Exploitability, Affected users, Discoverability), invece, viene utilizzato per assegnare un valore al rischio causato dalla minaccia. Può essere riadattato al caso industriale inserendo come nuovo fattore di valutazione l’Environmental Impact, diventando così DREADE.

Il risultato del passaggio di classificazione è dunque una lista ordinata di minacce su cui operare secondo il livello di rischio.

3.      Determinazione delle contromisure

Partendo dalla classificazione delle minacce si passa all’individuazione delle possibili contromisure da adottare.

Questo si traduce in tre possibili scelte:

• accettare il rischio dovuto alla minaccia;
• eliminare la minaccia, se possibile, operando sui componenti dell’architettura;
• mitigare la minaccia, implementando controlli compensativi (e.g. IDS, NDI, EDR, ecc.).

ICS e threat modeling: futuro prossimo

Il contesto industriale pone delle sfide uniche al mondo della cybersecurity. Questa breve e non esaustiva guida, mira ad essere un’infarinatura utile per affrontare queste sfide con un po’ più di consapevolezza e a spronare verso l’approfondimento dei temi trattati.

Fortunatamente, i professionisti della cybersecurity sono già al lavoro per aggiornare standard e framework, come il NIST 800-82, riadattandoli alle evoluzioni subite dall’industria. Questo presumibilmente renderà più semplice la scelta di quali misure di sicurezza adottare, riducendo i costi di analisi per le aziende.

Tuttavia, il threat modeling rimane uno strumento di valore inestimabile per tutti quegli operatori del settore che scelgono di seguire un approccio proattivo alla sicurezza.

Se sei interessato ad approfondire l’argomento scrivici a info@radsec.it o compila la form che si trova alla fine di questa pagina.

Riferimenti

Bongiorni, L. (2019, Settembre 21). How Threat Modelling Can Influence ICS Security Posture. Tratto da Kaspersky: https://ics.kaspersky.com/media/ics-conference-2019/01-Luca-Bongiorni-How-Threat-Modeling-can-Influence-ICS-Security-Posture.pdf

ENISA. (2011, Dicembre 09). Protecting Industrial Control Systems. Recommendations for Europe and Member States. Tratto da ENISA - European Union Agency for Cybersecurity: https://web.archive.org/web/20220716044705/https://www.enisa.europa.eu/publications/protecting-industrial-control-systems.-recommendations-for-europe-and-member-states/@@download/fullReport

Kamal, M. (2019, Gennaio 1). ICS Layered Threat - SANS Institute. Tratto da SANS: https://www.sans.org/reading-room/whitepapers/ICS/ics-layered-threat-modeling-38770

Mathezer, S. (2021, Luglio 16). Introduction to ICS Security Part 2. Tratto da SANS: https://www.sans.org/blog/introduction-to-ics-security-part-2/

OWASP. (2022, Settembre 4). Threat Modeling Process | OWASP Foundation. Tratto da OWASP: https://owasp.org/www-community/Threat_Modeling_Process

by RAD Staff

Next-gen Data Security Platform

Il costante aumento degli attacchi informatici, le nuove modalità di lavoro e l’utilizzo sempre più pervasivo di soluzioni SaaS, impone alle aziende di dover affrontare molteplici sfide relativamente alla protezione dei dati. Il contesto attuale infatti, ha portato all’insorgere di diverse esigenze, e la mancata applicazione di adeguate politiche di sicurezza introduce nuovi rischi. In quest’ottica diventa necessaria l’applicazione di una strategia specifica, modulare e ben integrata nell’intero contesto aziendale.

Un’occhiata al contesto...

Oggi più che mai le aziende, per poter rimanere competitive e aumentare la loro produttività, hanno la necessità di sviluppare il proprio business sulla base di processi, metodologie di lavoro e strumenti che garantiscano efficienza, agilità e snellezza.

Le nuove modalità di lavoro che, prima per necessità e poi per opportunità, hanno visto il personale aziendale spostarsi al di fuori del classico perimetro aziendale, hanno accentuato ancor di più sia la cooperazione con entità esterne (fornitori, clienti e partner) che la collaborazione tra colleghi. Tutto ciò ha ulteriormente alimentato la già crescente adozione di soluzioni cloud  e l’esternalizzazione di alcune funzioni di business.

Questa trasformazione, che rende le aziende sempre più digitali e fluide, oltre a portare dei vantaggi, richiede però il potenziamento delle proprie strategie di sicurezza.

Perchè è indispensabile proteggere i dati aziendali?

La proliferazione di dati dislocati sia su repository aziendali on-premise che su differenti servizi cloud, rappresenta un considerevole aumento della superficie d’attacco. Maggiore è il numero di dati esistenti, dei diversi repository e delle entità con cui vengono scambiati, maggiore è la probabilità che tali dati possano finire nelle mani sbagliate.

Anche in virtù del costante aumento degli attacchi informatici volti alla data exfiltration, le aziende si trovano sia a dover sottostare alle diverse normative in ambito di sicurezza, che a dimostrare di essere in grado di rispettarle pienamente.

Senza un’adeguata strategia di sicurezza e in assenza di una piattaforma di protezione dei dati di supporto, il rispetto di queste normative risulta estremamente dispendioso o addirittura impossibile. Non solo, l’elevata probabilità di subire attacchi informatici, amplificata dall’incapacità di avere una adeguata visibilità, gestione e protezione dei dati, rende molto più concreto il rischio di subire ingenti danni operativi, economici e reputazionali.

Quali tecniche sono state messe in campo nel corso del tempo?

Per ovviare ai problemi appena esposti, nel corso del tempo si è cercato di implementare diverse soluzioni di sicurezza. Tra gli esempi più significativi vi sono sicuramente sistemi come:

• Enterprise Digital Right Management (E-DRM)
• Data Access Control
• Data Loss Prevention (DLP)
• Cloud Access Security Broker (CASB)

Tuttavia, nessuna di queste soluzioni da sola è riuscita ad ovviare a tutti i problemi esposti sopra per due ragioni principali: limiti tecnologici e approccio non strutturato.

Spesso infatti, alcune soluzioni risultano efficacissime rispetto ad esigenze puntuali, ma mostrano diversi limiti tecnologici se adottate più ad ampio spettro. Questo ha comportato l’adozione, da parte delle aziende, di differenti soluzioni di sicurezza; tuttavia, a causa di un approccio non strutturato e senza una progettazione di insieme, l’adozione di queste soluzioni di sicurezza è avvenuta a “compartimenti stagni”. Questo non solo non ha permesso di ottenere i risultati sperati, ma ha fatto si che le singole iniziative potessero in qualche modo ostacolarsi a vicenda diminuendo ulteriormente l’efficacia delle singole soluzioni.

Qual è la piattaforma proposta da RAD?

Le caratteristiche fondamentali della piattaforma ideata da RAD, sono: focalizzazione sui dati, supporto ai processi di business, proattività e reattività e duplice modularità.

Focalizzazione sui dati

Grazie alla piattaforma che proponiamo, prima di tutto è possibile rifocalizzare la tecnologia rispetto all’obiettivo primario che accomuna le esigenze fin’ora descritte. Se infatti è fondamentale proteggere i dati aziendali, è altrettanto indispensabile sviluppare una stategia ed una piattaforma che agiscano direttamente sui dati rendendoli l’elemento centrale di politiche di sicurezza efficaci, robuste e resilienti.

Questa centralità del dato si declina in diversi aspetti e dimensioni:

1. Cifratura, gestione degli accessi e dei diritti dei dati. L’implementazione di queste tecniche permette di assicurare che i dati vengano acceduti, letti e modificati solo da chi ha l’autorizzazione necessaria e che siano protetti anche in caso qualcuno li esfiltrasse o li condividesse impropriamente.
2. Protezione a prescindere dalla dislocazione. Non importa se i dati sono conservati in repository on-premise, su piattaforme di collaborazione cloud o all’interno di basi dati strutturate. Con i giusti interventi e le adeguate funzionalità è possibile applicare la dovuta protezione al dato ovunque si trovi.
3. Tracciamento delle attività. La protezione dei dati è sicuramente fondamentale, ma lo è altrettanto la capacità di avere evidenza delle operazioni che gli utenti eseguono o tentano di eseguire.

Supporto ai processi di business

Essere in grado di applicare delle policy di accesso e protezione non è sufficiente. Al contrario è altrettanto importante avere una continua visibilità e consapevolezza di chi può avere accesso a quali dati, con quale livello di privilegio ed in virtù di quali autorizzazioni.

Per riuscire ad avere questo livello di dettaglio non sono sufficienti le sole informazioni di audit. Bensì, è necessario disporre di una piattaforma che sia in grado di integrarsi con i processi di business che trattano quei dati.

Se grazie alle regole di protezione si è in grado di determinare quale autorizzazione sia necessaria per accedere ad un dato, grazie alla gestione dei processi di business si riesce a definire chi possiede quell’autorizzazione e perchè.

Proattività e reattività

Una piattaforma di data security moderna ed evoluta, dovrebbe anche essere in grado di interagire con quei sistemi di sicurezza che governano i processi straordinari che, per intendersi, possono essere le differenti procedure organizzative relative a segnalazioni di anomalie di sicurezza. Grazie a questo tipo di integrazione, ad esempio, se si dovesse verificare un evento sospetto e malevolo, gli strumenti in dotazione alle strutture organizzative preposte (per es. EDR, XDR, SIEM, SOAR ecc.) non solo lo rileverebbero, ma avrebbero anche la possibilità di innescare le dovute azioni di remediation.

Un’efficace integrazione tra questi sistemi e una piattaforma di data security, combinata all’attenzione per i processi di business, consentirebbe anche di migliorare sia la proattività che la reattività nell’individuare e nel reagire a situazioni potenzialmente dannose.

Duplice modularità

Da un lato, la nostra piattaforma può essere formata dalle sole componenti di cui si ha la reale necessità, consentendo quindi di essere implementata “su misura” in relazione alle necessità dell’azienda. Dall’altro, questa modularità permette alla piattaforma di adattarsi e di evolversi progressivamente in funzione di una strategia di lungo termine e del conseguente grado di maturità che l’azienda desidera traguardare.

Approfondisci come implementare una strategia di sicurezza moderna e all’avanguardia che consenta di proteggere i dati aziendali e che al contempo non paralizzi l’operatività quotidiana.

by RAD Staff

Il penetration testing nel contesto moderno

Best practice e regole di compliance richiedono di effettuare Vulnerability Assessment e Penetration Testing (VA/PT) con cadenza periodica. Ma aldilà della conformità normativa, il Penetration Testing periodico è veramente utile e risolutivo per il corretto assessment della propria infrastruttura?

Sfide e criticità dei PT

Nell’ambito della cyber security, il PT è sicuramente una delle attività più complesse: richiede esperienza e competenze trasversali su tecnologie, metodologie e tecniche di test. Contrariamente ad altre attività che hanno un obiettivo ben specifico (es: monitorare un determinato rischio) o che sono intrinsecamente delimitate e con un punto di arrivo ben definito (es: analisi del codice, hardening, etc.), il PT ha l’obiettivo di “trovare problemi”, analizzando e combinando tra loro un insieme di elementi praticamente illimitato (vulnerabilità, tecnologie, configurazioni e comportamenti umani solo a titolo d’esempio).

Proprio per queste ragioni non esiste una scienza esatta sul PT e per quanto siano state sviluppate innumerevoli metodologie e framework per effettuare un PT, vi sono dei fattori che influenzano in maniera importante i risultati ottenuti da questo tipo di attività.

Il fattore umano

Per quanto si adoperino strumenti per l’analisi e la raccolta dei dati automatizzati (in alcuni casi anche per l’exploiting attivo), l’inventiva, l’intuizione e la capacità di combinare in maniera opportuna le evidenze raccolte la fanno da padrone nell’esecuzione di un PT insieme ad un adeguato bagaglio di conoscenze e competenze.

Ma l’influenza del fattore umano può essere sia positiva che negativa e in maniera piuttosto significativa. Se da un lato intuizioni, idee e conoscenze possono permettere di individuare strategie di attacco complesse, ma efficaci, dall’altra parte stanchezza, distrazione, stress o la sottovalutazione di un minimo particolare lo possono impedire.

Cosa significa tutto questo? A parità di infrastruttura e debolezze presenti, team diversi (ma anche lo stesso team in tempi diversi) potrebbero ottenere risultati anche molto distanti tra loro. Le differenze potrebbero derivare anche dai tool utilizzati, anche solo per la versione utilizzata (per l’introduzione di nuovi controlli o per la correzione di bug)

Il fattore tecnologico

Effettuare PT oggi, più che in passato, è particolarmente difficile perché ci si scontra con infrastrutture estremamente dinamiche e complesse, caratterizzate da architetture ibride (cloud e on-premise) e con innumerevoli stack applicativi in continua evoluzione, ognuno con le proprie peculiarità e vulnerabilità.

Tutto questo incrementa a dismisura il numero di fattori da tenere in considerazione, di strade da esplorare e delle superfici di attacco e obbliga i team dedicati al PT ad aggiornare i propri strumenti di test e il proprio bagaglio di competenze ad un ritmo sempre più serrato.

La variabilità delle architetture moderne può influenzare negativamente la validità temporale dei risultati ottenuti dato che l’aggiunta, la rimozione o l’aggiornamento di elementi architetturali potrebbero rimuovere o aggiungere vulnerabilità, chiudendo, o aprendo a loro volta, percorsi di attacco.

Il fattore tempo-costi

Il PT è una di quelle attività dove più si cerca e più è facile trovare qualcosa di rilevante perché il numero di elementi da considerare ed analizzare è molto ampio ed è arduo stabilire quando ogni dettaglio è stato considerato ed ogni strada esplorata.

Ma attività estensive e prolungate nel tempo possono portare a costi insostenibili per il cliente e nella ricerca del compromesso per coniugare le varie necessità (costi, livello di copertura etc.) si corre il rischio di sottodimensionare il team o di limitare in maniera significativa il perimetro di analisi o il tempo a loro disposizione.

Con tempi di esecuzione o perimetri ridotti c’è il forte rischio che alcuni percorsi rimangano inesplorati.  Ma mentre il tempo di un team di PT e dei team di cyber security è sempre limitato, il numero di potenziali attaccanti è molto ampio così come il tempo a loro disposizione. Il rischio potenziale? Avendo più tempo a disposizione, un attaccante ha maggiori possibilità di trovare un percorso di attacco che non è stato individuato durante il PT o di sfruttare una vulnerabilità scoperta successivamente.

Continuous Security Posture

Se alle precedenti osservazioni si aggiunge la maggiore attività di ricerca, con la scoperta quasi continua di vulnerabilità o tecniche di attacco e il rapido sviluppo di nuovi exploit, viene lecito porsi le seguenti domande:

• Per quanto tempo i risultati di un VA/PT possono considerarsi validi?
• Se un VA/PT non trova criticità, quanto e per quanto tempo si può stare “tranquilli”?

Forse un po’ meno di quanto previsto da alcune normative. A titolo d’esempio lo standard PCI DSS prevede un PT almeno una volta l’anno o a seguito di cambiamenti importanti.

Per queste ragioni la sicurezza di una infrastruttura non può dipendere solo dai PT e dai risultati da loro prodotti, ma è necessario un approccio integrato e continuo.

Integrato perché deve coinvolgere aspetti e tecnologie multiple come adeguate politiche di sicurezza, processi di Change Management e di Vulnerability Assessment e Management.

Continuo perché lo stato di esposizione di una infrastruttura può cambiare in qualunque momento per un cambiamento alle configurazioni, un errore umano o la scoperta di una nuova vulnerabilità. E più ampio è il lasso di tempo tra quando lo si scopre e vi si pone rimedio, maggiore è la probabilità che un attaccante se ne accorga.

Se per i Vulnerability Assessment è possibile eseguire delle scansioni automatiche e periodiche, sposando quindi il concetto di continuità, non si può dire lo stesso dei PT.
Fino ad ora almeno.

CVSS Severity Distribution Over Time
https://nvd.nist.gov/general/visualizations/vulnerability-visualizations/cvss-severity-distribution-over-time#CVSSSeverityOverTime

La nuova frontiera dell’Attack Simulation

Fedele alla propria filosofia di essere all’avanguardia e di attenzione al mercato e alle tecnologie di settore più moderne e promettenti, RAD ha di recente incluso nella propria offerta soluzioni di Attack Simulation automatizzate che senza mettere a rischio la disponibilità dei servizi (non vengono effettuate analisi invasive o l’esecuzione di exploit/Proof of Concept) sono in grado di effettuare un monitoraggio continuo dell’infrastruttura e di determinare tempestivamente come un attaccante potrebbe crearsi una via verso le zone più critiche a fronte di una nuova vulnerabilità scoperta o introdotta nell’ambiente.

XmCyber Attack Path
https://www.xmcyber.com/use-case/breach-and-attack-simulation/

L’automazione e la capillarità del monitoraggio consentono una migliore oggettività del risultato, un controllo estensivo e continuo dell’infrastruttura con la possibilità di rianalizzare tempestivamente ed agevolmente i percorsi di attacco e i rischi a fronte di cambiamenti infrastrutturali e di configurazione.

L’Attack Simulation non è sostitutiva del PT, che resta l’unico strumento per individuare le modalità di attacco più complesse, ma è sicuramente un ottimo supporto per il monitoraggio continuo e che sgrava i team di PT consentendogli di concentrarsi verso analisi e scenari di più alto livello che non sono automatizzabili.

Scopri come Rad può sopportare la tua azienda attraverso il suo competence center di Cyber Threat Identification and Simulation

by RAD Staff

Detection & Response: cambia il modo di pensare usando un approccio threat-centrico

Esiste una sostanziale differenza di approccio metodologico e mentale che bisogna adottare nel caso in cui si approfondiscano tematiche in ambito Detection & Response, rispetto a quando si lavora sul disegno delle architetture di sicurezza, e quindi nel mondo della Prevention.

Il modello threat-centrico rappresenta la chiave di lettura più giusta per guidare i clienti, a diversi livelli di maturità, su come approcciare e migliorare nelle attività d'individuazione e blocco di attacchi verso infrastrutture ed applicazioni.

Detection & Response: cambia mentalità!

La Cyber Security è un settore dell'informatica in rapida espansione e possiede all'interno diverse anime che caratterizzano le diverse professionalità coinvolte. Negli ultimi anni, con la crescita del settore, si è assistito alla nascita di nuovi rami, molti dei quali, soprattutto recentemente, orientati a tematiche offensive.

 La Detection & Response  è un ramo tradizionale della Cyber Security che rappresenta ancora la maggior parte delle attività e degli investimenti effettuati dai clienti di settore. Le piattaforme di sicurezza adottate dai clienti sono sempre di più e sempre più complesse (vedi migrazioni ibride sul cloud). La percezione è quella di ambienti sempre più sicuri viste le moltitudini di tecnologie adottate. Il quotidiano ci insegna però che gli attacchi andati a buon fine (o quasi) sono numerosi anche quando le architetture vengono disegnate in modo sicuro. Ciò accade perché le configurazioni sbagliate, le vulnerabilità 0-day e soprattutto la componente umana restano vettori di attacco più o meno critici.

Il primo passo per poter approcciare correttamente la tematica della Detection & Response è quella di accettare che le tecnologie di sicurezza non sempre sono la panacea di tutti i mali, e soprattutto che gli attacchi avvengono, e possono avvenire, per diversi motivi che vanno dal fallimento della tecnologia di sicurezza fino alla componente umana (che resta fondamentale) passando per le varie CVE che periodicamente vengono comunicate.

Le professionalità nell’ambito della Detection & Response (che restano variegate) sanno che devono intervenire quando tutte le tecniche di prevenzione hanno fallito e sanno anche che è fondamentale avere una Detection efficace ed efficiente per poter permettere una Response tempestiva.

Ma perché le tecnologie di sicurezza falliscono? I motivi possono essere tantissimi ma  è importante sottolineare che una buona Detection non può prescindere dall’accettazione del fallimento di tali tecnologie e architetture di sicurezza.

Esempi di Miss Detection

WAF

Le tecnologie Web Application Firewall (WAF) esistono da anni e sono tecnologie da poter considerare mature e consolidate. Tuttavia, molte di esse si basano su firme e regole non infallibili. Basti pensare al fatto che è impossibile pensare di monitorare tutte le URL possibili.

Nei casi in cui il tool di sicurezza fallisce o non può intervenire, ha senso monitorare altre sorgenti (es. Log dei webserver) per intercettare attacchi andati a buon fine e intervenire per tempo.

Gap Tecnologici

Nelle tecnologie di Cyber Security esistono dei gap tecnologici di vario tipo:

• Compatibilità tra le soluzioni di sicurezza e le tecnologie da difendere (es. OS non compatibili con l’antivirus/edr)
• Rollout incompleto delle soluzioni dovuto all’eterogeneità degli asset tecnologici coinvolti
• Bassa efficacia delle soluzioni rispetto a minacce specifiche (es. Antivirus classico a firma che non blocca comportamenti malevoli)

Generalmente è buona norma implementare dei monitoraggi di sicurezza in diversi fasi di un ipotetico attacco al fine di evitare di affidarsi ad un’unica tecnologia.

Obsolescenza

Non è sempre possibile mantenere aggiornato il proprio “parco macchine”. Di conseguenza, i diversi asset obsoleti possono sempre essere attaccati attraverso delle CVE note. Un monitoraggio attivo di specifici attacchi e minacce può sempre intervenire in ultima istanza a monitorare il rischio residuo (non azzerabile) e può portare all’attenzione degli analisti una serie di gap da colmare o non colmabili.

Uso improprio dei protocolli

In scenari avanzati di attacco ed in presenza di attaccanti esperti risulta sempre più difficile distinguere un comportamento malevolo da un comportamento lecito. Un protocollo lecito può essere utilizzato per eseguire attività malevole ed è possibile portare a termine attacchi senza che nessun tool di sicurezza intervenga.

Un classico esempio è l’utilizzo di specifici protocolli HTTP (es. Webdav) per l’esfiltrazione di dati senza che tecnologie atte al monitoraggio possano intervenire per motivi operativi o limiti tecnologici (es. DLP).

Efficienza ed efficacia del monitoraggio

Per ottimizzare la Detection & Response è fondamentale riuscire a focalizzare tempestivamente le forze di Response al fine di minimizzare gli impatti. In tal senso è molto importante monitorare:

• L’Efficacia della Detection: capacità d'individuare tempestivamente una minaccia o un’attività malevole in corso
• L’Efficienza della Detection: capacità di minimizzare la produzione di allarmi falsi positivi

E’ importante che gli allarmi di sicurezza siano poco rumorosi e precisi nell’individuazione di minacce. In tal senso, quello che bisogna chiedersi è quanto il proprio monitoraggio sia guidato dalle reali minacce che possono presentarsi, e quanto l’efficacia e l’efficienza della Detection siano massimizzate.

La massimizzazione dell’efficienza può essere ottenuta rivedendo i monitoraggi e re-ingegnerizzandoli, ove necessario, dando priorità alle regole di detection con minore efficienza

La massimizzazione dell’efficacia è invece legata all’approccio utilizzato per l’individuazione delle minacce.

L’approccio threat-centrico

L‘approccio threat-centrico consiste nel focalizzarsi sulle minacce e gli attacchi reali avendo come obbiettivo la massimizzazione dei parametri di detection e la mitigazione dei rischi residui più critici.

RAD accompagna i propri clienti nell’implementazione di un approccio threat centrico, al fine di colmare i gap di monitoraggio o migliorare il monitoraggio esistente.

Nella nostra esperienza, il miglioramento più significativo lo si riscontra con l’adozione del framework MITRE ATT&CK e l’analisi delle lesson learned degli incidenti passati.

In tal senso, RAD propone ai propri clienti una metodologia a fasi che permette in breve tempo di ottenere notevoli risultati:

• Adozione del MITRE ATT&CK framework
  • Viene effettuata una valutazione delle regole di detection attive, implementando una mappatura con le tecniche del MITRE ATT&CK e delle procedure di alert management da introdurre nella security operation
• GAP Analysis
  • Vengono analizzati i gap del monitoraggio secondo 3 diverse dimensioni: le tecniche non monitorate da nessuna regola, le tecniche parzialmente coperte su alcune tecnologie e scoperte su altre, le tecniche scoperte per cui non è necessario indirizzare alcun monitoraggio poiché non rappresentano alcuna minaccia
• Remediation Roadmap
  • Vengono analizzati i gap evidenziati nella fase precedente e proposta una roadmap di interventi di remediation atta a colmarli, tra i quali: Quick Win per la copertura di determinate tecniche o tecnologie, attività di red teaming atte a confermare la bontà delle coperture/scoperture e integrazione di nuove tecnologie di sicurezza

Scopri come RAD può aiutare la tua azienda attraverso il suo competence center di Cyber Security Monitoring 

by RAD Staff

Il mondo antifrode, oggi

Nel corso degli ultimi anni lo scenario delle frodi online si è evoluto di pari passo con la digital transformation. I processi e gli strumenti antifrode hanno dovuto adeguarsi a questa evoluzione e orientarsi verso un approccio omnicomprensivo, che tiene conto delle diverse sorgenti di rischio. Oggi, le frodi online non impattano più solo le banche e il commercio digitale e l'idea della "mitigazione del rischio" si è evoluta in un più ampio e complesso concetto di "digital trust".

L’evoluzione delle frodi online

Per anni, il mondo antifrode è stato focalizzato principalmente sul monitoraggio delle transazioni e sulla protezione della fase di login degli utenti. Obiettivo principale: identificare e prevenire movimenti di denaro “sospetti” e il cosiddetto Account Takeover (ATO).

Il panorama si è poi evoluto e attualmente copre una gamma molto più ampia di casi d’uso, coinvolgendo tipologie di aziende diverse: da quelle che storicamente sono state sempre più colpite e attente a queste problematiche, ovvero banche e commercio digitale, al mondo delle assicurazioni, delle telecomunicazioni, della salute, dell’educazione, dell’intrattenimento e, in generale, a qualsiasi business che offra prodotti o servizi online.

La digital transformation ha consentito l’introduzione di nuovi servizi e lo sviluppo di nuovi metodi e canali di pagamento. La volontà di attrarre una clientela sempre più ampia e quindi, anche, di creare servizi più facilmente fruibili, ha spinto le aziende a offrire ai propri clienti funzionalità e agevolazioni sempre più spinte, anche a discapito della sicurezza.

Questo, di conseguenza, ha alimentato nuovi scenari di frode.

Se storicamente il concetto di frode è sempre stato associato a quello di perdita diretta (un bonifico verso un IBAN fraudolento, ad esempio), lo scenario attuale ha ampliato questa prospettiva, includendo anche le cosiddette perdite indirette.

Identità Sintetiche

Le Identità Sintetiche sono identità digitali che vengono create online sfruttando un mix di dati veri e di dati contraffatti o attingendo completamente a dati rubati (reperiti, ad esempio, sul dark web o a valle di campagne di phishing). Queste identità derivano dai processi di creazione di account online che, molto spesso, sono disegnati per essere svolti interamente online, veloci e facili. Spesso, non sicuri.

Le identità sintetiche possono essere utilizzate per diversi scopi, a seconda del settore in esame. Nel campo finanziario, ad esempio, possono essere sfruttate per creare delle linee di credito fittizie o per riciclare denaro.

I rischi derivanti dalla creazione di account falsi variano a seconda del contesto ed in alcuni casi, come per il settore bancario, rappresentano una violazione della compliance normativa.

Policy Abuse

Nel Policy Abuse rientrano diversi scenari fraudolenti. Il concetto è usare impropriamente o abusare di un benefit messo a disposizione dal servizio.

Un esempio è il cosiddetto Bonus o Promotion Abuse, nel quale uno stesso utente sfrutta il multi-accounting per usufruire più volte delle promozioni all’iscrizione (come codici promozionali o free-trial) o per accumulare bonus derivanti da iniziative come le classiche “Invita un amico”.

Un altro esempio è legato invece alle politiche dei resi e dei rimborsi: un utente che acquista un prodotto, lo usa, e poi lo restituisce danneggiato (e quindi inadatto alla rivendita) oppure un utente che richiede un rimborso sostenendo (falsamente) di non aver mai ricevuto l’articolo.

Il Policy Abuse è uno scenario di frode molto ostico da contrastare poiché sfrutta direttamente le politiche che le aziende mettono in atto per consolidare il loro parco clienti e per attirarne di nuovi, e da cui devono derivare benefit competitivi e facili da ottenere.

Anche la tipologia di frodatori coinvolti varia molto: non solo frodatori professionisti ma anche semplici utenti “furbi”.

Content Abuse

Il termine Content Abuse si riferisce alla possibilità di pubblicare contenuti online che ingannano l’utente e ne influenzano le scelte.

Oggi, per un qualsiasi business online, la presenza di contenuti falsi può determinare il successo o l’insuccesso del brand. Il problema non risiede unicamente nella presenza del contenuto falso ma spesso da ciò che ne deriva.

Si pensi, ad esempio, ad un marketplace che ospita venditori che truffano gli acquirenti offrendo servizi o prodotti inesistenti o alla presenza di recensioni false, che direzionano le scelte dei consumatori.

Il panorama attuale, spesso privo di controlli in tal senso, alimenta l’ecosistema delle frodi che, in questo caso specifico, influisce in maniera importante anche sulla brand reputation e può essere la causa del brand abandonment.

Punti chiave di una strategia antifrode

I processi antifrode e le relative tecnologie e strumenti devono quindi essere capaci di gestire il rischio durante tutte le interazioni tra utente e servizio. Principalmente in tre fasi:

• Creazione dell’account
• Login dell’account
• Transazione o, genericamente, attività dell’account

Le tecnologie e gli strumenti a supporto sono di molteplice natura ma sicuramente includono due famiglie principali: i “classici” strumenti utilizzati per l’identificazione delle frodi (transaction e event monitoring, anti-malware e threat intelligence) e gli strumenti orientati alla verifica delle identità (strumenti di Identity Proofing and Affirmation, come behavioral biometrics, device fingerprint, sistemi di verifica dei documenti, etc..).

In quest’ottica, i punti critici riguardano essenzialmente due aspetti:

• La correlazione dei dati provenienti da sorgenti diverse consente ai motori di rischio di effettuare una profilazione più spinta e di costruire baseline di comportamento più solide. La correlazione può anche aiutare le analisi “post mortem”, facilitando i processi d'investigazione.
• L’orchestrazione dei diversi strumenti ha una duplice funzione: da un lato permette di collezionare i segnali di rischio dalle diverse sorgenti per coordinare un’unica azione di prevenzione; dall’altro consente di automatizzare molte attività svolte dagli analisti antifrode, spesso ripetitive e dispendiose (come la chiusura degli incidenti), andando a ottimizzare il processo e l’utilizzo degli strumenti stessi.

L’approccio RAD

Il contesto attuale impone un continuo trade-off tra sicurezza, user experience, compliance e ottimizzazione delle risorse (umane e tecnologiche).

Prendendo atto di tutti questi fattori, RAD supporta i suoi clienti nella definizione, valutazione, sviluppo e manutenzione delle strategie e delle soluzioni antifrode, adottando un approccio omnicomprensivo, che tiene conto delle tendenze e degli scenari attuali, con focus su tecnologie e processi.

Scopri come RAD può aiutare la tua azienda attraverso il suo competence center di Fraud Detection,Prevention & Response 

by RAD Staff