Framework di automazione della sicurezza serverless per AWS che acquisisce intelligence sulle minacce, applica rilevamento anomalie basato su ML (RCF, IP Insights) e arricchisce la telemetria di sicurezza in Kibana per prevenzione, rilevamento e risposta automatizzati alle minacce.
SyntheticSun è un framework di automazione e monitoraggio della sicurezza a difesa in profondità che utilizza threat intelligence, machine learning, servizi di sicurezza AWS gestiti e tecnologie serverless per prevenire, rilevare e rispondere continuamente alle minacce.
Dormi in vetro frammentato
Con riflessi di te,
Ma ti senti vivo?
Sì, lasciati chiedere,
Ti senti vivo?
- Norma Jean, 2016
SyntheticSun è costruito attorno all'uso della Malware Information Sharing Platform (MISP) e di Anomali's LIMO, che sono piattaforme di threat intelligence guidate dalla comunità (TIP) che forniscono vari tipi di indicatori di compromissione (IoC). Le threat intelligence normalizzate e deduplicate vengono confrontate in tempo quasi reale per identificare rapidamente minacce note in vari tipi di traffico di rete. Per aggiungere dinamismo all'identificazione di potenziali minacce, vengono distribuiti modelli IP Insights per trovare anomalie (e potenziali minacce al loro interno) tra l'abbinamento di indirizzi IP ed entità (come ID principal IAM, user-agent, ecc.), vengono utilizzati anche rilevatori RCF nativi in Elasticsearch per trovare anomalie nella telemetria di sicurezza in tempo quasi reale mentre viene trasmessa in streaming a Kibana. Per democratizzare l'uso e la messa a punto dei modelli ML all'interno dei team di sicurezza, vengono fornite utilità per addestrare i modelli IP Insights come componente aggiuntivo alla soluzione core.
Per eseguire sia l'orchestrazione e l'automazione, sia l'estrazione, trasformazione e caricamento (ETL) della telemetria di sicurezza in Kibana, vengono utilizzate varie tecnologie serverless AWS come AWS Lambda, Amazon DynamoDB e AWS CodeBuild. Tecnologie serverless come queste sono utilizzate per la loro scalabilità, facilità d'uso e costi relativamente bassi rispetto a soluzioni pesanti basate su MapReduce o Glue ETL. La maggior parte della soluzione viene distribuita tramite CloudFormation con script helper in Python e shell forniti attraverso i vari Stage per promuovere l'adozione e la potenziale distribuzione in pipeline di integrazione continua.
Per mantenere il più snello possibile il "cuore" della soluzione, moduli Python di base come boto3, requests, json, ipaddress, socket e re eseguono la maggior parte dell'estrazione, trasformazione e caricamento (ETL) nei servizi a valle. Poiché tutte le informazioni di geolocalizzazione sono fornite da ip-api.com, non richiede un account o livelli a pagamento e ha un'ottima API che include informazioni sulla limitazione nelle intestazioni delle risposte. Anche la maggior parte delle dipendenze di Elasticsearch e Kibana sono fornite nel codice (indici, mapping, visualizzazioni, ecc.) per evitare una configurazione manuale pesante.
SyntheticSun è suddiviso in tre Stage a causa delle dimensioni della soluzione e delle dipendenze richieste. Tutte le istruzioni di architettura e installazione (e FAQ dove appropriate) risiedono all'interno del proprio Stage. Vengono forniti anche moduli aggiuntivi (chiamati Appendice) per estendere la funzionalità, con le proprie istruzioni di architettura e installazione localizzate.
SyntheticSun, essendo qualcosa che hai trovato su GitHub, è una proof-of-concept e quindi non ho fatto il passo extra per la prima release per indurire assolutamente tutto. Supponendo che tu stia leggendo questo in un momento in cui non ho apportato le modifiche necessarie, considera quanto segue prima di distribuire questa soluzione in un ambiente di produzione (o qualsiasi ambiente con esigenze di sicurezza elevate). Metterò questi elementi in una roadmap e li aggiornerò come appropriato.
SyntheticSun è un modo semplice per iniziare a utilizzare la cyber threat intelligence e il machine learning per i tuoi casi d'uso di sicurezza perimetrale su AWS Cloud senza dover investire in uno o più strumenti commerciali, o assumere un data scientist per il tuo team di sicurezza (anche se idealmente dovresti fare quest'ultimo). Questa soluzione, dopo la configurazione iniziale, è completamente automatizzata, consentendoti di identificare e rispondere alle minacce a velocità macchina. Infine, questa soluzione fornisce visualizzazioni di base per il tuo team di incident response da utilizzare per la risposta alle minacce, come connessioni in entrata o in uscita consentite o query DNS verso indirizzi IP o domini considerati malevoli. Il nucleo della soluzione si basa su pipeline di automazione e data engineering molto leggere, che teoricamente possono essere riutilizzate per altri scopi dove sono necessarie normalizzazione e arricchimento a più stadi o job batch programmati e a ritmo serrato.
In primo luogo, se stai utilizzando Amazon GuardDuty e/o AWS WAF, potrebbe avere senso valutare questa soluzione, ma è anche un requisito. Personaggi ovvi che possono trarre vantaggio sono i team di prodotto responsabili della protezione del loro intero stack e che non hanno il capitale o l'esperienza per modellare, addestrare e distribuire algoritmi di machine learning o operazionalizzare i feed di cyber threat intelligence in modo significativo. Questi personaggi menzionati sono probabilmente security engineer, analisti/integrati SecOps/SOC o un ingegnere DevSecOps; tuttavia, questo elenco non è esaustivo e non devono necessariamente essere allineati al prodotto/applicazione poiché anche i team centrali possono usarlo. Un altro utilizzo è per gli stessi personaggi (SecOps, security engineering) che lavorano per un team centralizzato e vogliono creare una lista di blocco dinamica per firewall e sistemi di prevenzione delle intrusioni; i progetti CodeBuild possono essere riutilizzati per rilasciare CSV o file flat in quasi qualsiasi posizione (ad es. firewall Palo Alto, filtri URL del proxy forward Squid, ecc.).
SyntheticSun attualmente manca di copertura completa su tutte le principali fonti di log - in particolare, S3 Access Logs e CloudFront Access Logs, che sono integrali per il modo in cui molte persone erogano servizi (specialmente per SPA su bucket S3). Il rilevamento delle anomalie non si estende oltre WAF, API Gateway Access Logs o CloudTrail a causa della mia ossessione per IP Insights e della totale mancanza di formazione in data science (seriamente, non so nemmeno come usare pandas o numpy). Non c'è alcuna analisi approfondita degli IoC di threat intelligence grezzi oltre al tentativo di trovare corrispondenze nei log.
Il modo più semplice per distribuire questa soluzione per un'organizzazione è distribuirla in un account centralizzato di servizi di sicurezza. Per la telemetria di livello inferiore come VPC Flow Logs e WAF Logs, dovresti considerare di fornire script helper o modelli CloudFormation tramite AWS Service Catalog per promuovere l'abilitazione in ambienti inferiori. Dovrai valutare il consumo di shard e la rotazione degli indici di Elasticsearch Service, nonché le autorizzazioni, se avrai flussi di consegna Kinesis Data Firehose cross-account che pubblicano in una posizione centralizzata. Ho costruito questa soluzione nel mio account sandbox personale, quindi non ho integrato nessuna delle considerazioni sopra nella soluzione; sarò felice di lavorare su una PR con questo in mente e potrei farlo io stesso in futuro.
A partire dal 31 LUGLIO 2020, le Policy di AWS Firewall Manager supportano l'aggregazione multi-account del WAF Logging, il che ti avvicina di un passo a rendere tutto questo molto meno doloroso...
AVVERTENZE: Non sono un data scientist e questa sarà una risposta lunga. In breve: È un rilevatore di anomalie e penso di sì?
Dato che non sono nemmeno lontanamente un data scientist o ho una formazione, sei meglio servito leggendo la documentazione su questo. Detto ciò, ecco il mio tentativo da profano: IP Insights è un algoritmo di machine learning non supervisionato che impara la relazione tra un indirizzo IPv4 e un'entità (es. numero di account, nome utente, user-agent). IP Insights cerca quindi di determinare quanto è probabile che l'entità usi quell'indirizzo IPv4. Dietro le quinte di IP Insights c'è una rete neurale che apprende la rappresentazione vettoriale latente di queste entità e indirizzi IPv4. La distanza tra queste rappresentazioni vettorializzate è emblematica di quanto sia anomala (o meno) l'associazione di un'entità a (es. inviare una richiesta da) un indirizzo IPv4.
Le reti neurali sono quasi esattamente come sembrano; formano un sistema di machine learning progettato per comportarsi in modo simile al cervello umano, completo di neuroni e sinapsi computerizzati. Nel machine learning non supervisionato, l'algoritmo può capire come appare "buono" (cioè True Negative) rispetto a "cattivo" (cioè True Positive) guardando l'associazione tra tutti gli indirizzi IPv4 e le loro entità abbinate. Questa associazione viene valutata per identificare quali vettori sono simili agli altri per la loro "distanza". Nel caso di IP Insights, viene fornito un encoder pre-costruito che cerca indirizzi IPv4 e quindi raggruppa tutte le entità in cluster. Poi itera su di essi usando la vettorizzazione. La vettorizzazione è un modo per eseguire calcoli come matrice invece di iterare su di essi (pensa a un ciclo "For" per una lista contenente decine di milioni di valori).
Quando addestri un modello IP Insights, in realtà creerà da sé falsi positivi abbinando indirizzi IPv4 a entità che hanno una distanza elevata (cioè altamente anomale) e hanno meno probabilità di verificarsi nella realtà; il modello può ora discriminare tra True Positive, False Positive e True Negative. Questo viene fatto per prevenire un altro termine pazzesco chiamato "cross entropy" (AKA "log loss" come se fosse meglio), e introduce un altro termine, classificazione binaria. IP Insights essenzialmente chiede: "Qual è la probabilità che questo indirizzo IP abbinato a questa entità sia anomalo?" Questo è ciò che lo rende binario, penso, quindi "sì, è cattivo" o "no, non lo è". La probabilità è rappresentata come un valore tra 0 e 1, l'obiettivo di tutti i modelli di machine learning è renderlo il più vicino possibile a 0, quindi prevedere un valore di 0.01 per qualcosa che è realmente 1 (True Positive noto) comporterebbe una log loss molto elevata. Quindi, con tutto ciò, creando dati volutamente spazzatura, IP Insights aiuta a ridurre quella log loss (cioè previsioni errate) durante l'addestramento.
Questo ci porta all'output dell'endpoint. Quando lo interroghi (sia in batch che in tempo quasi reale usando l'API InvokeEndpoint), la risposta è un float illimitato che può essere negativo o positivo. Più è sopra 0, più è probabile che sia anomalo, ed è lì che inizia il tuo lavoro. Per questa soluzione ho scelto qualsiasi cosa sopra 0.03, che è in gran parte nozionale; per avvicinarti alla verità dovresti fornire True Positive all'endpoint e vedere qual è la tua risposta. In base a questi risultati, potresti configurare un approccio a livelli in cui la tua applicazione potrebbe emettere una sfida di secondo fattore, sollevare un avviso o bloccarlo completamente a seconda del punteggio. La risposta alla seconda parte della domanda è "Sì, penso di sì"; addestrare il modello con user-agent abbinati a un IP è in realtà piuttosto discutibile. Ora per altre entità meno volatili (numero di account, nome utente, utente IAM) sembra l'uso previsto.
Nella soluzione fornisco alcuni feed di esempio che dovresti usare, alcuni sono piuttosto ovvi come il feed dei domini di cybercrime, Emerging Threats e CI-badguys. Nel mio lavoro reale collaboro con una degli specialisti di cyber threat intelligence più talentuosi del mondo (senza scherzo, è fantastica!), che ha anche influenzato le scelte. Come i modelli di machine learning e tutto ciò che costruirai, dovresti personalizzare i tuoi feed di threat intelligence e l'aggregazione per adattarli al tuo attuale ambiente di minacce. I duplicati vengono identificati in MISP e solo una chiave hash è specificata nelle tabelle DynamoDB per imporre l'unicità, quindi anche se ci sono 5 feed che segnalano lo stesso indirizzo IPv4, solo uno arriverà nella tabella.
Puoi anche portare le tue piattaforme e feed di threat intelligence commerciali come InfoBlox o Recorded Future in questa soluzione puntandoli alle tabelle DynamoDB con sintassi simile.
La maggior parte della consegna dei log da AWS è "best effort", quindi non c'è un SLA ufficiale pubblicato; tuttavia, presumo che sia intorno al 99.5 - 99.9%, dove qualsiasi cosa in quell'ultimo 0.5 - 0.1% non verrà consegnata. Il traffico di "produzione" ha anche priorità in AWS; se ci sono vincoli di larghezza di banda di rete, darà priorità alla connettività verso i client rispetto all'invio dei log. L'evento più probabile è che il file di log grezzo fosse troppo grande per Lambda per elaborare l'intero file in tempo; lo vedi spesso quando vieni inondato da un DOS o da un crawler dallo stesso IP client. WAF e ALB raggruppano i file di log per chiamante (per quanto posso capire), quindi se assorbi centinaia di richieste, il file di log può essere molto grande.
Sì, tuttavia dovrai eseguire una delle seguenti operazioni:
Ci sono costi aggiuntivi per questo. Lambda in un VPC, specialmente per dozzine di invocazioni concorrenti, probabilmente porterà a più problemi a causa delle ENI che rimangono e consumano il tuo spazio RFC1918. A meno che tu non debba assolutamente isolare tutto il traffico all'interno del tuo VPC per soddisfare i requisiti di conformità, non percorrerei quella strada.
Sì, è realizzabile modificando la soluzione per pubblicare i log finali formattati in Kinesis Data Firehose e puntarli a Splunk.
Spero di avere supporto per Route 53 DNS Logs, S3 Access Logs, CloudFront Access Logs e API Gateway Access Logs e forse alcuni altri log basati su host in futuro.
Onestamente avrei preferito usare Kinesis Data Agent, ma ho riscontrato molti problemi con esso: Non è incluso per impostazione predefinita in Amazon Linux 2 e ora che le AMI Ubuntu 18.04 LTS includono Java 11 preinstallato, mi sono imbattuto in problemi di compatibilità all'indietro con l'Agente poiché fallisce la build a meno che non si abbia OpenJDK 8 o 9. È stato molto più facile installare l'Agente CloudWatch poiché viene aggiornato frequentemente con nuove funzionalità e c'è il supporto di Systems Manager Document per la configurazione; ha anche una procedura guidata per l'installazione. Se mai AWS prenderà sul serio il supporto di Kinesis Data Agent come quello di CloudWatch Agent, potrei passare ad esso poiché preferirei pubblicare direttamente su Kinesis Data Firehose per alcuni log basati su host (Suricata, Squid, Nginx, Apache) invece di usare CloudWatch Logs come intermediario.
Sono felice di accettare PR per elementi etichettati come "Help Wanted" in Issues o nel Project Board. Esaminerò anche qualsiasi altra PR proposta se soddisfa lo spirito del progetto.
Un ringraziamento speciale a David Dorsey e Ryan Nolette che hanno fornito feedback preziosi, test e contributi per aiutare a mettere a punto SyntheticSun.
Questa libreria è concessa in licenza secondo la GNU General Public License v3.0 (GPL-3.0) License. Consulta il file LICENSE.
