Log Collection tramite DomainTools: I vantaggi in una visione “Bird’s Eye”

02/09/2021

Nel post inaugurale di questa serie, tratteremo una visione “bird’s eye” del logging: motivi per cui è raccomandato avere una Log Collection tramite DomainTools, con indicazioni del settore e statistiche di logging, nella successiva serie di blog, tratteremo il ruolo della Collection mirata dei log in difesa, con indicazioni verso ricerche e casi d’uso. Teniamo anche a mente coloro che sono coinvolti nell’integrazione delle sorgenti di log e SIEM (come InsighIDR), e pubblicheremo una serie su Server DNS Linux e Windows e il deployment della log collection dei client, così come altre sorgenti di log (cloud, auditing, mail log, network defense log e altro ancora).

I log sono gli elementi costitutivi essenziali della sicurezza, uno dei casi d’uso più comuni riscontrati è stata la collection e l’integrazioni di log DNS, pertanto in questa serie ci concentreremo sulla collection dei log provenienti da DNS (server e client) e altre fonti di log che contengono IP, hostname e domain metadata.

Motivi per implementare una Log Collection

Quali sono i motivi per raccogliere i log? Una panoramica dei motivi principali include:

  • Risoluzione dei problemi operativi
  • Mantenere l’integrità dell’evento
  • Finalità di audit e conformità
  • Creazione di un server di gestione dei log centralizzato
  • Seguire le best practice e le linee guida sulla sicurezza. Ad esempio, essere in grado di rispondere a queste domande:
    • Quali sono gli eventi di sicurezza importanti da monitorare?
    • Quali sono i domini importanti e gli eventi DNS da monitorare?
  • Informare gli analisti con i dati di cui hanno bisogno per indagini, avvisi, rapporti e altro ancora.
  • Trovare lo spoofing o il dirottamento MITM (Man in the Middle) delle risposte DNS
  • Trovare prove di comunicazione con CnC (Command and Control)
  • Trovare prove di Social Engineering/Phishing (come l’uso attivo di domini ingannevoli)

Le ragioni e le motivazioni potrebbero non essere sufficienti, soprattutto se si ha il compito di ideare un piano per convincere l’azienda a iniziare o migliorare il logging. Fortunatamente nel settore sono già disponibili indicazioni, come illustrato nella sezione successiva.

Guida al logging dal settore Industry

Il consiglio è di utilizzare le linee guida del settore come punto di partenza per le distribuzioni dei log, assicurandosi che vi sia la possibilità di acquisire non solo i log DNS, ma anche altre fonti di log che contengono metadati preziosi come eventi di auditing e metadati contenenti indirizzi IP e hostname.

Palantir
La guida WEF (Windows Event Forwarding) di Palantir include eventi DNS sia client che server. Vedi il loro Github repository for WEF e un esempio WEF subscription configuration per DNS.

NSA
L’NSA ha pubblicato la “Windows Event Monitoring Guidance” che include i Windows Event Log channel come “Microsoft-Windows-DNS-Client” e “Microsoft-Windows-DNSServer” oltre ai nomi dei relativi provider Event Tracing for Windows (ETW). Vedi la loro Event Forwarding Guidance on Github.

Configurazione di esempio dalla NSA Event Monitoring Guidance:

<Query Id="0" Path="Microsoft-Windows-DNS-Client/Operational">
       <!-- 3008: DNS Client events Query Completed -->
       <Select Path="Microsoft-Windows-DNS-Client/Operational">*[System[(EventID=3008)]]</Select>
       <!-- Suppresses local machine name resolution events -->
       <Suppress Path="Microsoft-Windows-DNS-Client/Operational">*[EventData[Data[@Name="QueryOptions"]="140737488355328"]]</Suppress>
       <!-- Suppresses empty name resolution events -->
       <Suppress Path="Microsoft-Windows-DNS-Client/Operational">*[EventData[Data[@Name="QueryResults"]=""]]</Suppress>
     </Query>
     <Query Id="1" Path="DNS Server">
       <!-- 150: DNS Server could not load or initialize the plug-in DLL -->
       <!-- 770: DNS Server plugin DLL has been loaded -->
       <Select Path="DNS Server">*[System[(EventID=150 or EventID=770)]]</Select>
       <!-- NOTE: The ACL for Microsoft-Windows-DNSServer/Audit may need to be updated to allow read access by Event Log Readers -->
       <!-- 541: The setting serverlevelplugindll on scope . has been set to $dll_path -->
       <Select Path="Microsoft-Windows-DNSServer/Audit">*[System[(EventID=541)]]</Select>

 

OWASP (Open Web Application Security Project)

OWASP Top 10 Security Vulnerabilities for 2020 includevano logging e monitoraggio insufficienti. Hanno incluso questo tipo di vulnerabilità anche nel rapporto del 2017.

Da OWASP: Il logging e il monitoraggio insufficienti, insieme a un’integrazione mancante o inefficace con la risposta agli incidenti, consente agli aggressori di attaccare ulteriormente i sistemi, mantenere la persistenza, passare a più sistemi per manomettere, estrarre o distruggere i dati. La maggior parte degli studi sulle violazioni dimostra che il tempo necessario per rilevare una violazione è di oltre 200 giorni, in genere rilevati da parti esterne piuttosto che da processi interni o monitoraggio.

SANS Critical Controls

SANS Critical Controls (CIS Controls 7.1) ha il Sub Control 8.7 (Network) che include la raccomandazione: “Abilita il logging delle query DNS (Domain Name System) per rilevare la ricerca dell’hostname per domini C2 dannosi noti”.

Open Source

SwiftonSecurity Github Repo for Sysmon

Altre indicazioni: Indicazioni generali sulla raccolta dei log

 

Numeri di Log Deployment: Uno scenario

Al fine di soddisfare le esigenze di analisi degli IOC (Indicators of Compromise) e altre attività di threat hunting, nonché i requisiti operativi per soddisfare il lavoro SOC (come alerting e triage), le aziende richiedono i log data. Montagne di log data. Gli eventi di telemetria relativi al dominio e al DNS tendono a funzionare in tandem con altre origini dati di log, come i log di autenticazione o di auditing.

Sono necessarie ulteriori informazioni e dati: una volta che si conosce il punto di esfiltrazione (un dominio dannoso) tramite i log, quale punto di ingresso hanno utilizzato gli aggressori? E deve anche essere specifico. Ecco perché, ad esempio, l’Equifax 2017 post-mortem ha indicato che uno dei primi segnali dell’attacco era l’esecuzione del comando whoami su un server di destinazione.

Esempio di deployment di istanze Splunk

Quello che segue è un esempio reale di distribuzione su un’istanza Splunk. Di seguito sono riportati i dettagli:

  • Central Splunk Instance with capacity of 12TB
  • Up to 20TB effective capacity by the end of 2020
  • 50+ Splunk Universal Forwarders on Windows
  • 300+ Splunk Universal Forwarders expected by the end of 2020
  • Actual Volume of Data: 200 GB/Day
  • 300+ GB/Day expected by the end of 2020
  • 100 Source types
  • 650 independent log sources

Un elemento interessante da notare è che c’è una tendenza al rialzo per ampliare l’esposizione della fonte di log e, a sua volta, aumentare la raccolta di log.

Un esempio di deployment: Potential Logging Stats

Sulla base della cifra di oltre 300 GB/giorno dell’esempio precedente, il seguente è un potenziale

  • 7400 EPS (Events per Second)
  • 639,360,000 EPD (Events Per Day)
  • 90 Days Raw Log Retention
  • 90 Days SIEM Log Retention
  • 1:1 SIEM Storage Compression
  • 298 Total Raw Log Data (GB/day)
  • 893 Total Normalized Log Data (GB/day)
  • 26,820 GB Raw Storage Requirement
  • 80,370 Total SIEM Storage Requirement

Dove:

  • Total Raw Log Data (GB/day) value assumes 500 bytes log data.
  • Total Normalized Log Data (GB/day) value assumes 1500 bytes per stored record.

Il valore di 300+ GB/giorno è stato utilizzato per invertire il calcolo del numero di eventi di log che questo può indicare. È stato utilizzato un calcolatore di archiviazione SIEM (BuzzCircuit SIEM Storage Calculator*) per arrivare a un numero di 7400 eventi di log al secondo o 639 milioni di eventi di log al giorno. Va tenuto presente che questi sono eventi di log, non i dati di telemetria completi poiché non tutte le origini vengono loggate. Potrebbero esserci anche regole di analisi aggiuntive per questi log, come regole per deduplicare i log o eliminare metadati non importanti.

*Questi calcolatori sono un’utilità utile per il deployment, per capire quanto budget e infrastruttura sono necessari per soddisfare la capacità di raccogliere i log, oltre ai test di base.

 

Quando un utente raggiunge la fase in cui sta prendendo in considerazione un aiuto aggiuntivo, come le integrazioni di DomainTools o Iris, per facilitare il rilevamento delle minacce e l’analisi dei domini, potrebbe avere questi tipi di ambito da elaborare.

Che dire delle statistiche di logging del server DNS?
Si ptotrebbe anche voler avere un’idea di quali sono i numeri di generazione del log per gli eventi del server DNS. Il campione di server DNS da un documento Solarwinds sulla stima della generazione di log afferma che, per loro, “2 Windows DNS Server” per 1000 dipendenti possono generare 100 EPS o Events per Second (peak, average peak)*. Nel nostro calcolo, si tratta di un massimo di 8.640.000 EPD o Events per Day (based on peak).

Sulla base dei nostri calcoli:

  • 4GB/day Total Raw Log Data
  • 12 GB/day Total Normalized Log Data
  • 360 GB Raw Storage Requirement
  • 1080 Total SIEM Storage Requirement

*E’ stato incluso solo Solarwinds per gli events per second (in grassetto) poiché il resto sono numeri approssimativi calcolati da me in base al picco EPS noto.

Una cosa da tenere a mente è che le stime escludevano altre fonti di log. Anche le fonti aggiuntive sono interessanti e avrebbero fornito anche preziosi metadati come:

  • DNS Client events
  • Network connection logs, such as from Windows Firewall
  • FQDN metadata from proxy logs
  • Hostname (source and destination) from message tracking logs
  • DNS Query events

Ulteriori informazioni su queste sorgenti di log, inclusi gli esempi di log, saranno trattate in un futuro post del blog.

Conclusione

I difensori dovrebbero prestare particolare attenzione all’interno dei propri server DNS, ai log delle query DNS dei client, alle attività perimetrali della rete, mail log, proxy log e altro ancora. Le linee guida del settore Indutry, illustrano l’importanza della raccolta di questi (ad esempio DNS, IP, hostname, domain log). La distribuzione di un’attività di questo tipo non è un’impresa da poco per un’azienda, come mostrato dalle statistiche di distribuzione dei log.

Nei prossimi post di questa serie, mostreremo come le fonti di log forniscano la spina dorsale per la difesa, forniremo esempi di implementazione e mostreremo come i metadati rilevanti di questi log possano essere usati per la ricerca e l’analisi delle minacce. Quando vengono raccolti i log pertinenti, gli analisti sono in grado di creare una rappresentazione molto più completa degli IOC, da una potenziale intrusione non autorizzata tramite un portale di phishing ingannevole, esfiltrazione dannosa oltre la rete a un IP esterno e altro ancora.

Sfruttare i Log dalla sorgente al SIEM (e altro)

Bisogna sfruttare al massimo le fonti di logging pertinenti già esistenti nei propri ambienti e reti. Armato con i metadati giusti dal proprio server, client e endpoint di rete, è possibile migliorare e rafforzare le difese utilizzando DomainTools Iris, PhishEye e numerose API.

Risorse addizionali e’ possibile utilizzare le API per arricchire in modo programmatico i dati di log. Le Iris Investigate API e le Iris Enrich API, che elaborano le stesse origini dati di Iris, forniscono il Domain Risk Score dagli algoritmi di Proximity and Threat Profile. Consulta la documentazione API per saperne di più. Oltre alle API, è possibile utilizzare le integrazioni DomainTools per trovare informazioni sulle minacce nei metadati del proprio dominio.

Foto di Green Pass digitali e stampati fornite dai venditori ai loro acquirenti.

PUBBLICATO DA:<br>Domenico Panetta
PUBBLICATO DA:
Domenico Panetta
Presales Technical Engineer

ARTICOLI CORRELATI

Altre source utili per DNS e Domain logging

Altre source utili per DNS e Domain logging

Questo post finale tratta altre source utili per DNS e Domain logging che non sono stati trattati nei post precedenti. Questo post termina quindi con una nota di sfide da anticipare e idee per i passaggi successivi oltre la registrazione. Per una maggior comprensione...