Ingegneria presso Barracuda

La storia dietro Barracuda Active Threat Intelligence

Qualche tempo fa, durante una delle nostre sessioni di brainstorming, mentre i team discutevano del prossimo livello di evoluzione dei nostri prodotti, è diventato evidente che il rilevamento e la protezione contro le minacce nuove ed emergenti richiedevano un'analisi intensiva dei dati su larga scala. L'analisi dovrebbe prevedere il rischio dei clienti e farlo in modo efficiente e rapido, se vogliamo evitare che si verifichino azioni ostili.

Mentre analizzavamo i requisiti, ci siamo resi conto che per proteggerci da hacker avanzati come i bot, dovevamo creare una piattaforma in grado di analizzare il traffico per le sessioni web, correlarlo con i dati tra le sessioni e, per molte cose, nell'intera base clienti. Abbiamo anche capito che molte parti del sistema dovevano essere in tempo reale, alcune quasi in tempo reale, e altre potevano avere una fase di analisi molto più lunga.

Qualche anno fa abbiamo introdotto Barracuda Advanced Threat Protection (BATP) per la protezione dagli attacchi di malware zero-day su tutta la linea di prodotti Barracuda. Questa funzionalità, l'analisi dei file per rilevare il malware utilizzando più motori oltre al sandboxing, è stata introdotta nei prodotti di sicurezza delle applicazioni di Barracuda per proteggere applicazioni come i sistemi di elaborazione degli ordini in cui i file sono stati caricati da terze parti. Questo è stato il primo tentativo di utilizzare un livello basato su cloud per un'analisi avanzata che sarebbe stato difficile da integrare nelle appliance firewall per applicazioni web.

Sebbene il livello cloud di BATP fosse in grado di gestire milioni di scansioni di file, avevamo bisogno di un sistema in grado di archiviare grandi quantità di metadati in modo che potessero essere analizzati per individuare minacce nuove e in evoluzione. Questo ci ha fatto iniziare il percorso verso la prossima piattaforma di intelligence sulle minacce.

Come funziona Active Threat Intelligence

La piattaforma Barracuda Active Threat Intelligence è la nostra risposta. La piattaforma è costruita su un enorme data lake, che può gestire l'elaborazione in streaming e l'elaborazione in batch dei dati. Elabora milioni di eventi al minuto, in tutte le aree geografiche, e fornisce informazioni utili per rilevare bot e attacchi lato client, oltre a fornire informazioni per la protezione da tali vettori di minacce. Barracuda Active Threat Intelligence è costruita con un'architettura aperta per essere in grado di evolversi rapidamente per affrontare le nuove minacce.

Oggi la piattaforma Barracuda Active Threat Intelligence riceve i dati dai motori di sicurezza di Barracuda Web Application Firewall e WAF-as-a-Service, nonché da altre fonti. Man mano che gli eventi vengono ricevuti, vengono arricchiti utilizzando feed di minacce di crowdsourcing e altri database di intelligence. L'analisi dettagliata di questi eventi, sia individualmente che come parte di una sessione utente, viene utilizzata per classificare i clienti come umani o bot.

Le pipeline di analisi dei dati utilizzano vari motori e modelli di machine learning per analizzare più aspetti del traffico e raggiungere le loro raccomandazioni, che vengono infine riconciliate per produrre il verdetto finale.

In che modo Active Threat Intelligence aiuta a proteggere le tue app

Oltre a supportare tutte le analisi richieste per la protezione avanzata dai bot, la piattaforma Active Threat Intelligence viene utilizzata per le nostre ultime offerte: protezione lato client e motore di configurazione automatizzato.

Active Threat Intelligence tiene traccia di tutte le risorse esterne che possono essere utilizzate dall'app, ad esempio un JavaScript esterno o un foglio di stile. Tenere traccia delle risorse esterne ci assicura di essere consapevoli della superficie delle minacce e di poterci proteggere da attacchi come MageCart e altri.

Poiché i metadati raccolti sono estremamente ricchi, siamo in grado di ricavarne informazioni aggiuntive per assistere gli amministratori fornendo consigli di configurazione basati sul traffico reale che arriva alle loro app.

Questa piattaforma è stata fondamentale per aiutarci a creare la prossima generazione di funzionalità di protezione richieste dai nostri clienti. Continuiamo a sfruttare questa piattaforma scalabile per raccogliere informazioni approfondite sui modelli di traffico, sul consumo delle applicazioni e altro ancora. Non perderti i post sul blog dei nostri team di ingegneri che parleranno di come abbiamo sviluppato Barracuda Advanced Threat Intelligence.

Anshuman Singh

Anshuman Singh è Senior Director Product Management presso Barracuda. Entra in contatto con lui su LinkedIn qui.

www.barracuda.com

Registrazione di eventi altamente scalabile su AWS

La maggior parte delle applicazioni genera eventi di configurazione ed eventi di accesso. È importante che gli amministratori abbiano visibilità su questi eventi. Barracuda Email Security Service offre trasparenza e visibilità su molti di questi eventi per aiutare gli amministratori a perfezionare e comprendere il sistema. Ad esempio, sapere chi ha effettuato l'accesso all'account e quando. Oppure sapere chi ha aggiunto, modificato o eliminato la configurazione di un determinato criterio.

Per creare questo sistema distribuito e ricercabile, sorgono molte domande, come:

• Come si dovrebbero scrivere questi log da tutte le applicazioni, i servizi e le macchine in una posizione centrale?
• Quale dovrebbe essere il formato standard dei file di log?
• Per quanto tempo è necessario conservare questi log?
• Come si dovrebbero correlare gli eventi di applicazioni diverse?
• Come si fa a fornire un meccanismo di ricerca semplice e veloce tramite un'interfaccia utente per l'amministratore?
• Come si rendono disponibili questi log tramite un'API?

Quando si pensa a un motore di ricerca distribuito, la prima cosa che viene in mente è Elasticsearch. È altamente scalabile con ricerca quasi in tempo reale ed è disponibile come servizio completamente gestito in AWS. Quindi, il percorso è iniziato pensando di archiviare questi log degli eventi in Elasticsearch, con tutte le diverse applicazioni che inviavano i log a Elasticsearch utilizzando Kinesis Data Firehose.

Componenti coinvolti in questa architettura

1. Kinesis Agent – Amazon Kinesis Agent è un'applicazione software Java autonoma che offre un modo semplice per raccogliere e inviare dati a Kinesis Data Firehose. L'agente monitora continuamente i file di log degli eventi sulle istanze Linux EC2 e li invia al flusso di distribuzione Kinesis Data Firehose configurato. L'agente gestisce la rotazione dei file, il checkpoint e la ripetizione dei tentativi in caso di errori. Fornisce tutti i tuoi dati in modo affidabile, tempestivo e semplice. Nota: se l'applicazione che deve scrivere su Kinesis Firehose è un container Fargate, avrai bisogno di un container Fluentd. Tuttavia, questo articolo si concentra sulle applicazioni in esecuzione su istanze Amazon EC2.
2. Kinesis Data Firehose – Il metodo direct put di Amazon Kinesis Data Firehose può scrivere i dati in formato JSON in Elasticsearch. In questo modo non memorizza alcun dato sul flusso.
3. S3 – Un bucket S3 può essere utilizzato per eseguire il backup di tutti i record o dei record che non vengono consegnati a Elasticsearch. I criteri del ciclo di vita possono anche essere impostati per l'archiviazione automatica dei log.
4. Elasticsearch – Elasticsearch ospitato da Amazon. L'accesso a Kibana può essere abilitato per facilitare l'interrogazione e la ricerca nei log per qualsiasi scopo di debug.
5. Curator – AWS consiglia di utilizzare Lambda e Curator per gestire gli indici e gli snapshot del cluster Elasticsearch. AWS ha maggiori dettagli ed esempi di implementazione che possono essere trovati qui
6. Interfaccia API REST – Puoi creare un'API come astrazione per Elasticsearch, che si integra bene con l'interfaccia utente. Le architetture di microservizi basate su API si sono dimostrate le migliori sotto molti aspetti, come la sicurezza, la conformità e l'integrazione con altri servizi.

Scalabilità

• Kinesis Data Firehose: per impostazione predefinita, i flussi di consegna Firehose possono scalare fino a 1.000 record/s o 1 MiB/s per gli Stati Uniti orientali (Ohio). Si tratta di un limite flessibile che può essere aumentato fino a 10.000 record/s. Questo è specifico per regione.
• Elasticsearch: il cluster Elasticsearch può essere dimensionato sia in termini di storage che di potenza di calcolo su AWS. Sono possibili anche aggiornamenti di versione. Amazon ES utilizza un processo di distribuzione blu/verde per l'aggiornamento dei domini. Ciò significa che il numero di nodi nel cluster potrebbe aumentare temporaneamente durante l'applicazione delle modifiche.

Vantaggi di questa architettura

1. L'architettura della pipeline è gestita in modo completo ed efficacemente e richiede pochissima manutenzione.
2. Se il cluster Elasticsearch si guasta, Kinesis Firehose può conservare i record per un massimo di 24 ore. Inoltre, i record che non riescono a essere consegnati vengono sottoposti a backup su S3.

Con queste opzioni disponibili, le possibilità di perdita di dati sono basse.

3. Il controllo granulare degli accessi è possibile sia per Kibana che per l'API Elasticsearch tramite i criteri IAM.

Difetti

1. I prezzi devono essere attentamente considerati e monitorati. Kinesis Data Firehose è in grado di gestire grandi quantità di dati inseriti con facilità e se un agente non autorizzato inizia a registrare grandi quantità di dati, Kinesis Data Firehose li consegnerà senza problemi. Ciò può comportare costi elevati.
2. L'integrazione di Kinesis Data Firehose in Elasticsearch è supportata solo per i cluster Elasticsearch non VPC.
3. Al momento Kinesis Data Firehose non è in grado di distribuire i log ai cluster Elasticsearch non ospitati da AWS. Se si desidera ospitare autonomamente i cluster Elasticsearch, questa configurazione non funzionerà.

Conclusione

Se sei alla ricerca di una soluzione completamente gestita e (per lo più) scalabile senza interventi, questa sarebbe una buona opzione da prendere in considerazione. Il backup automatico su S3 con criteri del ciclo di vita risolve facilmente anche il problema della conservazione e dell'archiviazione dei log.

Sravanthi Gottipati

Sravanthi Gottipati è responsabile di ingegneria della sicurezza e-mail presso Barracuda Networks. Puoi entrare in contatto con lei su LinkedIn qui.

www.barracuda.com

DJANGO-EB-SQS: Un modo più semplice per le applicazioni Django di comunicare con AWS SQS

I servizi AWS come Amazon ECS, Amazon S3, Amazon Kinesis, Amazon SQS e Amazon RDS sono ampiamente utilizzati in tutto il mondo. Noi di Barracuda utilizziamo AWS Simple Queue Service (SQS) per gestire la messaggistica all'interno e tra i microservizi che abbiamo sviluppato sul framework Django.

AWS SQS è un servizio di accodamento messaggi in grado di "inviare, archiviare e ricevere messaggi tra componenti software a qualsiasi volume, senza perdere messaggi o richiedere la disponibilità di altri servizi". SQS è progettato per aiutare le organizzazioni a disaccoppiare le applicazioni e scalare i servizi ed è stato lo strumento perfetto per il nostro lavoro sui microservizi.  Tuttavia, ogni nuovo microservizio basato su Django o il disaccoppiamento di un servizio esistente utilizzando AWS SQS richiedeva la duplicazione del codice e della logica per comunicare con AWS SQS. Ciò ha comportato la ripetizione di un sacco di codice e ha incoraggiato il nostro team a creare questa libreria GitHub: DJANGO-EB-SQS

Django-EB-SQS è una libreria python pensata per aiutare gli sviluppatori a integrare rapidamente AWS SQS con applicazioni, nuove e/o esistenti, basate su Django. La libreria svolge i seguenti compiti:

• Serializzazione dei dati
• Aggiunta della logica di ritardo
• Polling continuo dalla coda
• Deserializzazione dei dati secondo gli standard AWS SQS e/o utilizzo di librerie di terze parti per comunicare con AWS SQS.

In breve, estrae tutta la complessità coinvolta nella comunicazione con AWS SQS e consente agli sviluppatori di concentrarsi solo sulla logica di business principale.

La libreria si basa sul framework Django ORM e la libreria boto3.

Come la usiamo

Il nostro team lavora a una soluzione di protezione dell'e-mail che utilizza l'intelligenza artificiale per rilevare lo spear phishing e altri attacchi di social engineering. Ci integriamo con l'account Office 365 dei nostri clienti e riceviamo notifiche ogni volta che ricevono nuove e-mail. Uno dei compiti è determinare se la nuova e-mail è priva di frodi o meno. Alla ricezione di tali notifiche, uno dei nostri servizi (Figura 1: Servizio 1) comunica con Office 365 tramite l'API Graph e riceve tali e-mail. Per un'ulteriore elaborazione di tali e-mail e per renderle disponibili per altri servizi, esse vengono quindi inviate alla coda AWS SQS (Figura 1: queue_1).

Figura 1

Esaminiamo un semplice caso d'uso su come utilizziamo la libreria nelle nostre soluzioni. Uno dei nostri servizi (Figura 1: Servizio 2) è responsabile di estrarre le intestazioni e i set di caratteristiche dalle singole e-mail e di renderle disponibili per il consumo da parte di altri servizi.

Il servizio 2 è configurato per ascoltare queue_1 per recuperare i corpi delle e-mail non elaborati.

Supponiamo che il Servizio 2 esegua le seguenti azioni:

# consuma i messaggi e-mail dalla queue_1

…

# estrai le intestazioni e i set di caratteristiche dalle e-mail

…

# invia un'attività

process_message.delay(tenant_id=, email_id=, headers=, tenant_id=, feature_set=,...)

Questo metodo process_messagenon non verrà richiamato in modo sincrono, ma sarà messo in coda come attività e verrà eseguito quando uno dei worker lo raccoglierà. Il worker in questione potrebbe provenire dallo stesso servizio o da un servizio diverso. Il chiamante del metodo non deve preoccuparsi del comportamento sottostante e di come l'attività verrà eseguita.

Diamo un'occhiata a come il metodo process_message viene definito come attività.

from eb_sqs.decorators import task

@task(queue_name='queue_2′, max_retries=3)
def process_message(tenant_id: int, email_id: str, headers: List[dict], feature_set: List[dict], …) :

Prova:

# esegui alcune azioni utilizzando le intestazioni e i set di caratteristiche
# è anche possibile mettere in coda altre attività, se necessario

except(OperationalError, InterfaceError) as exc:

Prova:

process_message.retry()

except MaxRetriesReachedException:

logger.error(‘MaxRetries reached for Service2:process_message ex: {exc}')

Quando decoriamo il metodo con il decoratore di attività, ciò che accade a livello interno è che vengono aggiunti dati extra come il metodo chiamante, il metodo di destinazione, i suoi argomenti e alcuni metadati aggiuntivi prima che il messaggio venga serializzato e inviato alla coda AWS SQS. Quando il messaggio viene consumato dalla coda da uno dei worker, contiene tutte le informazioni necessarie per eseguire l'operazione: quale metodo chiamare, quali parametri passare e così via.

È anche possibile riprovare l'attività in caso di eccezione. Tuttavia, per evitare uno scenario di loop infinito, possiamo impostare un parametro opzionale max_retries, dove è possibile interrompere l'elaborazione dopo aver raggiunto il numero massimo di tentativi. Possiamo, quindi, registrare l'errore o inviare l'attività a una coda di messaggi non recapitabili per un'ulteriore analisi.

AWS SQS offre la possibilità di ritardare l'elaborazione del messaggio fino a 15 minuti. Possiamo aggiungere una funzionalità simile alla nostra attività passando il parametro delay:

process_message.delay(email_id=, headers=, …., delay=300) # ritardo di 5 min

L'esecuzione delle attività può essere ottenuta eseguendo il comando Django process_queue. Questo supporta l'ascolto di una o più code, la lettura delle code all'infinito e l'esecuzione delle attività man mano che arrivano:

python manage.py process_queue –queues

Abbiamo appena visto come questa libreria semplifica la comunicazione all'interno del servizio o tra i servizi tramite le code di AWS SQS.

Maggiori dettagli su come configurare la libreria con le impostazioni di Django e la capacità di ascoltare più code, la configurazione dello sviluppo e molte altre funzionalità sono disponibili qui.

Contribuire

Se desideri contribuire al progetto, fai riferimento qui: DJANGO-EB-SQS

Rohan Patil

Rohan Patil è Principal Software Engineer presso Barracuda Networks. Attualmente sta lavorando a Barracuda Sentinel, un sistema di protezione basata su IA contro il phishing e il furto di account. Negli ultimi cinque anni ha lavorato alle tecnologie cloud e negli ultimi dieci anni ha ricoperto vari ruoli nell'ambito dello sviluppo di software. Ha conseguito un Master in Informatica presso la California State University e una Laurea in Informatica a Mumbai, in India.

Entra in contatto con Rohan su LinkedIn qui.

www.barracuda.com

Utilizzo di GraphQL per API robuste e flessibili

La progettazione delle API è un'area in cui possono esserci molte controversie tra gli sviluppatori di applicazioni client e gli sviluppatori di backend. Le API REST ci hanno permesso di progettare server stateless e di accedere in modo strutturato alle risorse per oltre due decenni e continuano a servire il settore, principalmente grazie alla loro semplicità e alla curva di apprendimento moderata.

REST è stato sviluppato intorno all'anno 2000, quando le applicazioni client erano relativamente semplici e il ritmo di sviluppo non era così veloce come lo è oggi.

Con un approccio tradizionale basato su REST, la progettazione si baserebbe sul concetto di risorse gestite da un determinato server. Poi, si farebbe tipicamente affidamento su verbi HTTP come GET, POST, PATCH, DELETE per eseguire operazioni CRUD su tali risorse.

Dagli anni 2000 sono cambiate diverse cose:

• L'aumento dell'uso di applicazioni su singola pagina e di applicazioni mobili ha creato l'esigenza di un caricamento efficiente dei dati.
• Molte architetture backend sono passate da un modello monolitico a un'architettura a microservizi (µservice) per cicli di sviluppo più rapidi ed efficienti.
• Per le API è necessaria una varietà di client e consumatori. REST rende difficile la creazione di un'API che supporti più client, in quanto restituirebbe una struttura di dati fissa.
• Le aziende si aspettano di lanciare le funzionalità più rapidamente sul mercato. Se è necessario apportare una modifica sul lato client, spesso richiede una regolazione lato server con REST, con conseguente rallentamento dei cicli di sviluppo.
• Una maggiore attenzione all'esperienza utente spesso porta alla progettazione di visualizzazioni/widget che richiedono dati da più server di risorse API REST per il rendering.

GraphQL come alternativa a REST

GraphQL è un'alternativa moderna a REST che mira a risolvere diverse carenze e la sua architettura e i suoi strumenti sono costruiti per offrire soluzioni per le pratiche di sviluppo software contemporanee. Consente ai client di specificare esattamente quali dati sono necessari e consente di recuperare i dati da più risorse in un'unica richiesta. Funziona in modo più simile a RPC, con query denominate e mutazioni invece di azioni obbligatorie standard basate su HTTP. Questo approccio dà il controllo a chi di competenza: lo sviluppatore dell'API di backend specifica ciò che è possibile e il client/consumatore dell'API specifica ciò che è necessario.

Ecco un esempio di query GraphQL, che mi ha aperto gli occhi quando l'ho incontrata per la prima volta. Supponiamo di costruire un sito web di microblogging e che sia necessario eseguire una query per trovare 50 post recenti.

query recentPosts(count: 50, offset: 0) {
id
title
tags
content
author {
id
name
profile {
email
interests
}
}
}

La query GraphQL di cui sopra ha lo scopo di richiedere:

• Ultimi 50 post
• ID, titolo, tag e contenuto per ogni post del blog
• Informazioni sull'autore contenenti ID, nome e informazioni sul profilo.

Se dovessimo utilizzare un approccio API REST tradizionale, il client dovrebbe effettuare 51 richieste. Se i post e gli autori sono considerati risorse separate, si tratta di una richiesta per ottenere 50 post recenti e poi 50 richieste per ottenere informazioni sull'autore per ogni post. Se le informazioni sull'autore fossero incluse direttamente nei dettagli del post, allora si potrebbe fare tutto con una sola richiesta API REST. Ma nella maggior parte dei casi, quando modelliamo i nostri dati utilizzando le migliori pratiche di normalizzazione dei database relazionali, gestiamo le informazioni sull'autore in una tabella separata, e questo porta le informazioni sull'autore ad essere una risorsa API REST separata.

Ecco la parte interessante di GraphQL. Supponiamo che, in una visualizzazione mobile, non abbiamo spazio sullo schermo per mostrare sia il contenuto del post che le informazioni sul profilo dell'autore. La query potrebbe ora essere:

query recentPosts(count: 50, offset: 0) {
id
title
tags
author {
id
name
}
}

Il client mobile ora specifica le informazioni che desidera e l'API GraphQL fornisce i dati esatti richiesti, niente di più e niente di meno. Non è stato necessario modificare il server, né il codice lato client ha subito cambiamenti significativi. Inoltre, il traffico di rete tra client e server è ottimale.

Il punto da notare qui è che GraphQL ci consente di progettare API flessibili in base ai requisiti lato client piuttosto che da una prospettiva di gestione delle risorse lato server. Una percezione generale è che GraphQL abbia senso solo per architetture complesse che coinvolgono diverse dozzine di microservizi. Questo è vero in una certa misura, dato che c'è una certa curva di apprendimento con GraphQL rispetto alle architetture API REST. Ma questo divario si sta colmando, con significativi investimenti intellettuali e finanziari da parte di una nuova fondazione vendor-neutral in rapida crescita.

Barracuda è uno dei primi ad adottare le architetture GraphQL. Se questo post ha suscitato il tuo interesse, segui questo spazio per i miei post successivi, dove approfondirò i dettagli tecnici e i vantaggi architettonici.

Vinay Patnana

Vinay Patnana è responsabile di ingegneria del servizio di sicurezza e-mail presso Barracuda.  In questo ruolo, assiste nella progettazione e nello sviluppo dei servizi di scalabilità delle soluzioni e-mail di Barracuda.

Vinay ha conseguito un Master in Informatica presso la North Carolina State University e una laurea in Ingegneria presso il BIT Mesra, in India.  Lavora con Barracuda da diversi anni e vanta un'esperienza decennale di lavoro con diverse varietà di stack tecnici.  Puoi entrare in contatto con lui su LinkedIn qui.

www.barracuda.com