Domenico Panetta, Autore a DotForce.it

DomainTools annuncia l’acquisizione di Farsight Security per fornire una Best-in-class Threat Intelligence

da Domenico Panetta | Nov 10, 2021 | Notizie dal Mercato

L’acquisizione supporta l’investimento dell’azienda in capacità di intelligence sulle minacce predittive in tempo reale per una difesa proattiva contro le minacce emergenti.

SEATTLE, 10 novembre 2021 – DomainTools, leader nell’intelligence sui domain name e sulle minacce informatiche basata su DNS, ha annunciato oggi l’acquisizione di Farsight Security, leader nell’intelligence DNS e nelle soluzioni di sicurezza informatica passive DNS. L’acquisizione rappresenta una naturale estensione della partnership di lunga data di entrambe le società per fornire i dati passive DNS leader di mercato di Farsight tramite la piattaforma di indagine Iris di DomainTools per valutare il rischio, mappare l’infrastruttura degli aggressori e aumentare rapidamente la visibilità e il contesto sulle minacce.

La mossa arriva quando il ransomware è diventato una delle più grandi minacce finanziarie per l’economia globale. Secondo un rapporto del Financial Crimes Enforcement Network (FinCEN), una filiale del Dipartimento del Tesoro degli Stati Uniti, il ransomware è costato agli Stati Uniti quasi 600 milioni di dollari nella prima metà del 2021. Per combattere questa e altre minacce online, i team di sicurezza hanno bisogno di complete capacità di intelligence e indagine per identificare in anticipo i modelli dietro l’infrastruttura avversaria che possono aiutarli ad anticipare e difendersi in modo proattivo contro le mosse future degli attori delle minacce.

I dati di osservazione DNS leader di mercato di Farsight, combinati con i migliori dati DNS attivi di DomainTools, offrono ai clienti lo sguardo più tempestivo e completo sulle minacce che emergono al di fuori della loro rete. Farsight Security DNSDB® è il database di intelligence DNS più grande al mondo con oltre 100 miliardi di record di risoluzione del dominio aggiornati in tempo reale con oltre 300.000 risoluzioni DNS uniche al secondo in tutto il mondo. DomainTools Iris è una piattaforma di indagine e intelligence sulle minacce proprietaria che combina informazioni di livello superiore sull’infrastruttura DNS e di dominio e punteggio di rischio con i dati DNS passivi leader del settore di Farsight Security.

“DomainTools e Farsight hanno dimostrato per molti anni il valore dei nostri set di dati combinati e delle nostre soluzioni di intelligence integrate. La nostra soluzione unificata viene utilizzata da alcune delle organizzazioni di sicurezza più sofisticate in tutto il mondo per aumentare l’efficacia delle loro capacità di intelligence sulle minacce e di risposta agli incidenti”, ha affermato Tim Chen, CEO, DomainTools. “Questa acquisizione migliora la nostra capacità di guidare i risultati di rilevamento, indagine, arricchimento e mitigazione della sicurezza per i nostri clienti comuni, accelerando i nostri progressi nella scienza dei dati per il punteggio predittivo del rischio di nomi di dominio, nomi host, indirizzi IP, server dei nomi e altri indicatori DNS”.

“Nel corso degli anni, DomainTools e Farsight hanno costantemente fornito intelligence DNS leader di mercato e telemetria di sicurezza in tempo reale necessarie per difendersi dagli attacchi informatici di oggi”, ha affermato il dott. Paul Vixie, presidente, cofondatore e CEO di Farsight Security. “Riconosciamo l’immenso opportunità che questa acquisizione rappresenta non solo per entrambe le società, ma anche per i nostri clienti globali. Siamo entusiasti di unirci a DomainTools in questa prossima fase della crescita dell’azienda e, insieme, contribuiamo a rendere Internet più sicuro per tutti”.

Informazioni su DomainTools
DomainTools, supportato dalla società di investimento globale Battery Ventures, consente ai professionisti della sicurezza di anticipare gli attacchi identificando l’infrastruttura degli aggressori, ottenendo un contesto e una visibilità immediati sulle minacce ed effettuando valutazioni dei rischi più rapide, migliorando così notevolmente la posizione di sicurezza della loro organizzazione. Le aziende Fortune 1000, le agenzie governative globali e i principali fornitori di soluzioni di sicurezza utilizzano la piattaforma DomainTools come ingrediente fondamentale nel loro lavoro di indagine e mitigazione delle minacce. Scopri di più su come collegare i punti sulle attività dannose su https://www.domaintools.com o su Twitter: @domaintools.

Informazioni su Farsight Security, Inc.
Farsight Security, Inc. è un fornitore leader di dati DNS passivi storici e in tempo reale, inclusa la sua soluzione di punta, DNSDB, il più grande database DNS passivo al mondo. Consentiamo ai team di sicurezza di qualificare, arricchire e correlare tutte le fonti di dati sulle minacce e, infine, risparmiare tempo quando è più critico, durante un attacco o un’indagine. Le nostre soluzioni forniscono al personale e alle piattaforme aziendali, governative e del settore della sicurezza una visibilità, un contesto e una risposta globali senza pari. Farsight Security ha sede a San Mateo, California, USA. Scopri di più su come possiamo potenziare la tua piattaforma per le minacce e il tuo team di sicurezza con le soluzioni DNS passive di Farsight Security su https://www.farsightsecurity.com/ o su Twitter: @FarsightSecInc.

Le 7 cose da ricercare nelle passwordless authentication solutions

da Domenico Panetta | Nov 4, 2021 | Notizie dal Mercato

La recente mossa di Microsoft di offrire l’autenticazione passwordless come authentication solutions, per gli account dei consumatori ha suscitato sospiri di sollievo dagli esperti di sicurezza di tutto il mondo, poichè le password sono tra i rischi per la sicurezza più significativi per individui e aziende. Un recente sondaggio ha rilevato che il 65% delle persone riutilizza le password tra gli account e il 45% non ha modificato la propria password nell’ultimo anno, anche dopo una violazione. Con semplici ed economici attacchi di credential stuffing e di password spraying, le password sono l’equivalente di chiudere a chiave una porta ma lasciare la chiave sotto il tappetino.

Molte soluzioni di autenticazione a più fattori (Multi Factor Authentication o MFA) aggiungono semplicemente un altro fattore di autenticazione oltre alla password, tuttavia gli aggressori possono utilizzare diversi metodi come phishing, Man in the Middle (MitM) o Push Attacks per ottenere l’accesso a interi sistemi. Alcune soluzioni di autenticazione che si definiscono “passwordless”, nonostante il loro nome, rientrano in questa categoria. Ecco perché le recenti direttive MFA e le linee guida sulle migliori pratiche mirano a spostare l’autenticazione verso metodi sicuri e resistenti al phishing per dimostrare l’identità.

A parte i problemi di sicurezza, alcune soluzioni di autenticazione passwordless sono eccessivamente complicate, causando frustrazione tra gli utenti, altre invece aggiungono complessità nelle integrazioni per i team IT o non sono scalabili a livello aziendale. Qui esaminiamo le principali domande che è necessario porre a qualsiasi potenziale fornitore sulla loro soluzione di autenticazione passwordless

Utilizza comunque le password?

Questo dovrebbe essere ovvio, ma molti cosiddetti provider passwordless offrono una “esperienza” senza password piuttosto che un prodotto veramente senza password. Possono utilizzare funzionalità di convenienza biometrica senza password come TouchID o FaceID per l’interfaccia utente, ma queste semplicemente sbloccano una password memorizzata da inviare per l’autenticazione. Oppure le soluzioni inviano una password monouso (OTP) tramite SMS o e-mail come parte del flusso MFA. Per definizione, una OTP è ancora una password e come tutte le altre password è vulnerabile alle stesse minacce di phishing e intercettazione.Sebbene l’autenticazione tramite infrastruttura a chiave pubblica (PKI) sia stata a lungo considerata il metodo più sicuro, la disponibilità di soluzioni basate su PKI di facile utilizzo e business è relativamente recente. Assicurati che la soluzione di autenticazione passwordless scelta sfrutti una solida crittografia e non utilizzi modalità di autenticazione non sicure come password, OTP o token SMS in qualsiasi punto del flusso di accesso.

Fornisce MFA passwordless per l’accesso desktop?

L’accesso sicuro all’applicazione è importante, tuttavia il punto di autenticazione iniziale per la maggior parte della forza lavoro è il proprio dispositivo. Se la soluzione di autenticazione passwordless che utilizzi funziona solo per le applicazioni, stai lasciando aperta una falla di sicurezza critica per la tua forza lavoro. Inoltre, con gli obblighi normativi, come l’ordine esecutivo sul miglioramento della sicurezza informatica della nazione, e gli assicuratori informatici che insistono sull’implementazione dell’MFA per ottenere la copertura, l’autenticazione desktop è ora uno degli imperativi legali e aziendali.La soluzione di autenticazione passwordless scelta, dovrebbe offrire diverse opzioni di autenticazione sicura per i desktop della forza lavoro, idealmente con la stessa esperienza di accesso utente delle applicazioni. Inoltre, è necessaria una funzionalità di autenticazione offline sicuraquando i dipendenti sono in viaggio o non sono in grado di connettersi a Internet.

È una soluzione certificata FIDO o FIDO2 dall’inizio alla fine?

Fast Identity Online (FIDO) è un insieme di standard aperti per migliorare la sicurezza informatica riducendo la dipendenza dalle password. Essere certificati FIDO® significa implementare la crittografia a chiave pubblica per l’autenticazione e aderire agli standard di usabilità e interoperabilità per favorire l’adozione da parte degli utenti e garantire la compatibilità con altri prodotti certificati FIDO.Alcuni fornitori affermano di essere conformi a FIDO o supportano FIDO, il che non garantisce la stessa sicurezza, usabilità e interoperabilità della certificazione FIDO. È anche possibile che un provider abbia la certificazione FIDO per il suo server di convalida, ma un autenticatore non certificato. Ciò significa che il loro server è in grado di accettare verificatori di autenticazione certificati FIDO esterni, ma che il client della soluzione stesso non soddisfa gli standard FIDO.

Gli standard FIDO corrispondono alle linee guida del NIST (800-63B), della FFIEC, dell’OMB e di altri statuti sulla sicurezza informatica, nonché ai requisiti di PSD2 Strong Customer Authentication. L’utilizzo di una soluzione completamente certificata FIDO significa conformità integrata. Per determinare lo stato di certificazione di una soluzione di autenticazione passwordless, è possibile controllare il registro delle tecnologie certificate FIDO a questo indirizzo.

La soluzione è in grado di interagire ed integrarsi con il tuo Identity Provider (IdP)?

I provider di identità (IdP)come OneLogin e Azure AD sono essenziali per mantenere la sicurezza del sistema, in particolare per le aziende con una forza lavoro distribuita. Con l’enorme <passaggio al lavoro da casa negli ultimi anni, l’aumento della superficie di attacco degli utenti che accedono da ambienti non sicuri o dispositivi condivisi minaccia l’integrità di intere reti. Gli IdP rafforzano questi potenziali vettori di attacco, quindi una soluzione di autenticazione passwordless deve integrarsi con qualunque IdP si stia utilizzando.Molte soluzioni “senza password” funzionano solo con IdP specifici o tentano di sfruttare il loro prodotto per bloccare le organizzazioni al proprio IdP. Si consiglia di disaccoppiare l’autenticazione dall’Identity Provider. Qualunque sia la soluzione di autenticazione passwordless che si sceglierà di utilizzare, dovrebbe integrarsi con tutti i principali IdP e supportare standard aperti (come SAML o OIDC) per integrarsi facilmente con il servizio SSO di tua scelta.

È facile da integrare e distribuire?

Un grosso ostacolo alla sostituzione dei sistemi obsoleti di autenticazione basati su password, è rappresentato dalle potenziali difficoltà e disservizi durante l’implementazione di una nuova tecnologia, e questo non deve accadere. Una soluzione di autenticazione passwordless che segue un approccio basato su standard, dovrebbe essere facile da integrare con i provider SSO già presenti. Inoltre, le soluzioni che forniscono un robusto SDKconsentono ai team di sviluppo di integrarsi facilmente con applicazioni personalizzate o legacy non connesse al proprio provider SSO. Se gli obblighi normativi come la PSD2 Strong Customer Authentication (SCA) influiscono sulla tua attività, assicurati che gli SDK della soluzione includano controlli di sicurezza integrati e funzioni per aiutarti a soddisfarli.

Com’è l’esperienza dell’utente?

L’esperienza dell’utente e la facilità d’uso di qualsiasi sistema di sicurezza, gioca un ruolo chiave nella sua adozione di successo e rende molto meno probabile che le persone cerchino soluzioni alternative per motivi di convenienza o facilità. Sfortunatamente, molte soluzioni di autenticazione passwordless, si concentrano esclusivamente sull’aspetto della sicurezza e dimenticano la User Experience (UX). Se la tua soluzione passwordless richiede più tempo rispetto alla digitazione di una password, la tua organizzazione avrà difficoltà a adottarla.I fornitori di soluzioni devono rendere l’esperienza di autenticazione veloce, intuitiva e conveniente, oltre che tenere conto delle preferenze degli utenti. Una solida soluzione di autenticazione passwordless dovrebbe anche fornire alternative per coloro che non possono o non vogliono utilizzare la biometriao il proprio smartphone.

Oltre a soddisfare i tuoi utenti, una soluzione di autenticazione efficace e veloce offre un ROI migliore attraverso una maggiore produttività e un risparmio di tempo per i reparti IT.

Come vengono archiviate le chiavi private sui dispositivi?

Una soluzione di autenticazione passwordless può comunque essere vulnerabile agli attacchi sui dispositivo da parte di hacker, anche se utilizza la crittografia a chiave pubblica. Malware, attacchi side-channel e reverse engineering sono tra le tante tecniche a disposizione degli aggressori che vogliono rubare le chiavi private di un sistema crittografico. Per garantire la sicurezza delle chiavi sui dispositivi mobili, i sistemi di autenticazione dovrebbero utilizzare la sicurezza basata sull’hardware, come la tecnologia TrustZone di ARM, gli ambienti di esecuzione affidabile di Android, l’enclave sicura di iOS o Samsung KNOX per archiviare le chiavi ed eseguire operazioni crittografiche.

True Passwordless™ MFA

L’implementazione di una soluzione di autenticazione passwordless efficace, è fondamentale per la conformità normativa, l’ottenimento di gare d’appalto e la riduzione dei costi assicurativi informatici. Tuttavia, molti fornitori che affermano di offrire tale soluzione offrono semplicemente una “esperienza” senza password o una sicurezza scadente. Inoltre, le soluzioni spesso si rivelano difficili da integrare con gli IdP preesistenti, o rendono improbabile l’adozione con interfacce scadenti o contorte.

HYPR fornisce una True Passwordless™ MFA che trasforma un normale smartphone in una chiave di sicurezza supportata da PKI, per un’esperienza di autenticazione familiare e semplice. In qualità di sistema di autenticazione completamente certificato FIDO, HYPR si impegna a migliorare la sicurezza e l’interoperabilità del sistema, mettendo al contempo in primo piano le esigenze della tua forza lavoro e dei tuoi clienti.

Per saperne di più sulle soluzioni di autenticazione passwordless HYPR, contattaci.

Vai al post originale

Brute Force Attack, cos’è e come proteggersi?

da Domenico Panetta | Ott 28, 2021 | How-To

Abbiamo visto tutti i titoli su questa o quell’azienda che è stata hackerata a causa di un Brute Force Attack, e chiunque potrebbe essere in grado di dare una definizione abbastanza buona di cos’è.

Cos’è un brute force attack?

“Un brute force attack (attacco forza bruta), nella Cyber Security, è una forma di attacco in cui l’autore dell’attacco utilizza un approccio per tentativi ed errori, di decodificare le password. Molto probabilmente stanno usando un programma o un bot per generare password probabili o anche set di caratteri casuali.”

Se ottengono la giusta combinazione di nome utente e password, possono entrare nei sistemi e raggiungere i dati delle aziende e/o dei loro clienti che saranno ora esposti. Esiste due tipi specifici di Brute Force Attack:

Dictionary Attack (Attacco a Dizionario), in cui invece di utilizzare solo set di caratteri casuali, gli aggressori utilizzano elenchi di parole o frasi comuni per indovinare le password.
Credential Stuffing, che utilizza nomi utente e password reali ottenuti da altri data breach.

Quindi si sa che il problema è là fuori, ma come è possibile rilevarlo e ancora più importante come è possibile prevenirlo?

Come rilevare un brute force attack

Il miglior piano per rilevare un brute force attack, è disporre di un sistema in grado di monitorare i tentativi di accesso e avvisare quando vengono superate determinate soglie (es. InsightIDR di Rapid7 o Netwrix Auditor), che permette di:

Monitorare un numero insolitamente elevato di tentativi di accesso provenienti da un singolo indirizzo IP, che potrebbe indicare un bot in esecuzione da quell’indirizzo IP, e che sta tentando rapidamente diverse combinazioni di nome utente e password.
Impostare un avviso quando si verifica un forte aumento dei tentativi di accesso in un determinato periodo di tempo. Questo aumento insolito potrebbe anche suggerire un programma che tenta automaticamente di accedere a diversi set di credenziali.
Rilevare possibili credenziali compromesse correlando un numero elevato di tentativi di accesso non riusciti a determinati account. Gli utenti spesso riutilizzano le stesse credenziali per più sistemi e gli aggressori riutilizzano le credenziali che potrebbero aver rubato da un sistema per entrare in un altro.

Sfortunatamente, anche se si imposta un sistema di monitoraggio e si riceve una notifica su questi diversi tipi di comportamenti insoliti, si potrebbe non essere in grado di agire abbastanza velocemente da impedire agli aggressori di entrare. Quindi è necessario assicurarsi di essere protetti da questi tipi di attacchi in primo luogo.

4 modi per prevenire un brute force attack.

Ci sono alcune semplici modifiche alla configurazione che si possono mettere in atto per prevenire attacchi brute force.

Utilizzare password complesse e la loro scadenza.
Bloccare (anche temporaneamente) gli account dopo un numero ragionevole di tentativi falliti.
Implementare l’autenticazione a più fattori (MFA).
Verificare la presenza di credenziali compromesse.

Utilizzare password complesse e la loro scadenza.

Uno dei modi più semplici per rallentare almeno gli aggressori è applicare password complesse. Attraverso criteri per le password come quelli che possono essere applicati con le User Policies di OneLogin o tramite il Password Filter di SpyCloud AD Guardian, è possibile richiedere che tutte le password debbano essere almeno una combinazione di lettere maiuscole, lettere minuscole, numeri e di 12 caratteri, oltre che vietare l’utilizzo di determinate password tramite una blacklist. La complessità e la lunghezza si aggiungono al numero di possibili combinazioni che un bot dovrà affrontare in un semplice attacco brute force.

È inoltre possibile richiedere agli utenti di aggiornare o creare periodicamente una nuova password. Poiché i semplici attacchi brute force possono richiedere tempo per eseguire tutte le possibilità, una password modificata significherebbe che sono tornati al punto di partenza e tutti i tentativi precedenti sono stati inutili.

Bloccare (anche temporaneamente) gli account dopo un numero ragionevole di tentativi falliti.

Se il sistema di autenticazione ne ha la capacità, si dovrebbe impostare un numero massimo di tentativi di accesso e assicurarsi che l’account venga bloccato una volta superato quel numero. Ciò garantirà che l’aggressore non possa continuare a tentare di accedere a quell’account a tempo indeterminato.

Implementare l’autenticazione a più fattori (MFA).

Gli aggressori potrebbero riuscire a capire la combinazione di nome utente e password attraverso tentativi ed errori, ma è molto più difficile per loro sfruttare un fattore di autenticazione aggiuntivo come un token hardware (come Yubico) o software (come HYPR). L’MFA richiede che un utente fornisca qualcosa oltre al proprio nome utente e password. Potrebbero dover fornire un’impronta digitale o una password monouso (OTP) o avere a portata di mano un particolare hardware come il loro telefono o un token USB per confermare il fattore di autenticazione aggiuntivo. È molto più difficile per gli aggressori falsificare queste forme aggiuntive di autenticazione.

Funzionalità come SmartFactor Authentication di OneLogin fanno un ulteriore passo avanti. SmartFactor fornisce l’autenticazione adattiva e tiene conto del contesto in cui viene effettuato il tentativo di accesso: la posizione geografica, l’indirizzo IP, il dispositivo, ecc. SmartFactor utilizza un motore AI (Vigilance AI), per formare un profilo che riflette il comportamento tipico di un utente. Pertanto, quando una richiesta di accesso proviene da una posizione da cui l’utente non ha mai tentato di accedere prima, quel tentativo di accesso può essere semplicemente bloccato.

Verificare la presenza di credenziali compromesse.

Gli hacker hanno grandi database di nomi utente e password conosciuti costruiti nel tempo dall’hacking di vari sistemi. Gli utenti tendono a riutilizzare le stesse combinazioni di nomi utente e password per tutte le applicazioni a cui devono accedere perché è difficile ricordare un mucchio di credenziali diverse. Gli hacker lo sanno e ne traggono vantaggio utilizzando le credenziali di quei database nei loro brute force attack. Controllando le credenziali di un utente con elenchi noti di credenziali compromesse e costringendolo a scegliere una nuova password quando c’è una corrispondenza, è possibile impedire agli utenti di utilizzare gli stessi set di credenziali che gli hacker proveranno. Questo può rallentare la loro capacità di entrare perché ora devono fare affidamento sulla loro capacità di provare un mucchio di password generate casualmente per entrare.

La funzionalità SmartFactor Authentication di OneLogin o SpyCloud ATO, prevedono la possibilità per un amministratore di abilitare i controlli delle credenziali compromesse di Active Directory come delle caselle e-mail aziendali e personali, permettendo di assicurarsi che gli utenti non inseriscano o stiano utilizzando password già a disposizione degli utenti malintenzionati.

Gli hacker stanno diventando sempre più efficienti nell’entrare nei sistemi. Quando entrano, le aziende possono perdere denaro e la fiducia dei propri clienti. Dobbiamo tutti rimanere sempre vigili e mettere in atto adeguate misure di protezioni per impedire che si verifichino attacchi di questo tipo.

SpyCloud nominata “Overall Threat Detection Solution of the Year” 2021

da Domenico Panetta | Set 30, 2021 | Notizie dal Mercato

Il prestigioso programma di premi internazionali premia i prodotti e le aziende di sicurezza delle informazioni eccezionali.

Austin, TX – 30 settembre 2021 – SpyCloud, leader nella prevenzione dell’account takeover (ATO), ha annunciato oggi di essere stata nominata vincitrice del premio “Overall Threat Detection Solution of the Year” nella quinta edizione dei CyberSecurity Breakthrough Awards. Il programma di premi è condotto da CyberSecurity Breakthrough, un’organizzazione leader di intelligence di mercato indipendente che riconosce le migliori aziende, tecnologie e prodotti nel mercato globale della sicurezza delle informazioni oggi.

SpyCloud agisce come un sistema di allerta precoce per avvisare in modo proattivo i team di sicurezza quando le credenziali sono state compromesse in modo che possano agire rapidamente per bloccare l’account. SpyCloud è in grado di recuperare i dati compromessi da violazioni di mesi, a volte anni, prima che vengano condivisi ampiamente all’interno della rete criminale. SpyCloud ospita anche il database più solido di informazioni sulle minacce di credenziali compromesse e PII: oltre 130 miliardi di risorse. Solo nell’ultimo anno, i ricercatori di SpyCloud hanno recuperato più di 4,6 miliardi di record di informazioni di identificazione personale e 1,5 miliardi di credenziali di account rubate sul dark web.

L’impareggiabile capacità di SpyCloud di recuperare rapidamente i dati rubati consente alla piattaforma di prevenire attacchi informatici basati sull’identità come l’acquisizione dell’account, che provoca ransomware, compromissione della posta elettronica aziendale, furto di identità e frode con carta di credito.

“La criminalità informatica è arrivata alla ribalta della coscienza pubblica con importanti attacchi alla catena di approvvigionamento che hanno un impatto sulle infrastrutture del paese. Nonostante l’urgenza del problema, la maggior parte delle aziende fa ancora fatica a rilevare e prevenire gli attacchi informatici derivanti dall’uso di credenziali rubate”.

e ancora

“Miriamo a essere la piattaforma più completa per l’acquisizione di account e la prevenzione delle frodi sul mercato, sfruttando la qualità dei nostri dati e la velocità con cui possiamo identificare le esposizioni per aiutare le aziende a combattere i criminali informatici”.

ha affermato Ted Ross, CEO e co-fondatore di SpyCloud.

La missione dei CyberSecurity Breakthrough Awards è quella di onorare l’eccellenza e riconoscere l’innovazione, il duro lavoro e il successo in una gamma di categorie di sicurezza delle informazioni, tra cui Cloud Security, Threat Detection, Risk Management, Fraud Prevention, Mobile Security, Email Security e molte altre. Il programma di quest’anno ha attirato più di 4.000 nomination da oltre 20 paesi diversi in tutto il mondo.

“La prevenzione si basa spesso su misure di difesa tradizionali come la protezione degli endpoint invece di concentrarsi sull’origine di un gran numero di questi attacchi, con le credenziali degli account degli utenti finali. La combinazione unica di intelligenza umana di SpyCloud, recupero precoce dei dati e la più ampia raccolta di dati sulle violazioni del settore consente alle aziende di trovare più compromessi, stare al passo con gli attacchi difficili da rilevare e proteggere dipendenti, consumatori e i loro profitti.

ha affermato James Johnson, amministratore delegato di CyberSecurity Breakthrough.

Vai al post originale

Altre source utili per DNS e Domain logging

da Domenico Panetta | Set 27, 2021 | How-To, Notizie dal Mercato

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 dei contenuti, è consigliato aver letto i precedenti post di questa serie:

Altre source di log rilevanti
Sono disponibili aggiuntive source di event log, che contengono metadati preziosi. Tool IDS/IPS, log del firewall, mail log, utilizzano tutti metadati per estrarre indirizzi IP, hostname e altri metadati per informare ulteriormente il lavoro di IR e di threat hunting. Gli indirizzi IP possono essere utilizzati per risalire e indagare sull’infrastruttura, oppure utilizzare i dati per condurre una reverse IP dell’hostname per orientarsi verso i domini associati e trovare il Threat Profile e il Risk Score. La prima metà di questa sezione copre brevemente altre fonti e fornisce esempi approfonditi nella metà finale.

Managed DNS Provider
Amazon Route 53 DNS Query Logging e CloudWatch
Configurare Amazon Route 53 per raccogliere i log delle informazioni sulle query DNS pubbliche ricevute da Route 53 (consultare la Guida per gli sviluppatori). I metadati disponibili sono simili ad altre fonti di registrazione delle query DNS: dominio o sottodominio richiesto, data e timestamp, tipo di record DNS, codice di risposta DNS e edge location di Route 53 che ha risposto alla query DNS. Se si utilizza Amazon CloudWatch Logs per monitorare, archiviare e accedere ai file di log delle query DNS, è possibile anche trasmettere questi log alla propria istanza LM e SIEM.

Google Cloud DNS
Google Cloud DNS Logging, tiene traccia delle query che i server dei nomi risolvono per le reti VPC (Virtual Private Cloud). Sono disponibili altri Managed DNS Provider, controllare la loro documentazione per vedere come impostare query e response logging.

Proxy Server Log
I Proxy Server Log sono una fonte comune di informazioni per i metadati del dominio. Questi log contengono le richieste effettuate all’interno della rete sia dagli utenti che dalle applicazioni.

DNS Packet Log
Oltre ad acquisire e ascoltare i pacchetti su strumenti di analisi di rete, è anche possibile impostare il logging dei pacchetti e configurarlo per raccogliere solo i log dei pacchetti di determinati protocolli come i pacchetti DNS. Tuttavia, l’acquisizione e la registrazione dei pacchetti fornisce solo i metadati relativi al DNS. Non è possibile, ad esempio, ottenere maggiori dettagli sull’host da cui questo evento ha avuto origine o quale utente specifico o azione dell’utente ha attivato quell’evento.

Log generati da tool IDS/IPS
I log generati da tool IDS/IPS, come regole e avvisi, possono essere raccolti e inoltrati al proprio LM/SIEM. Alcuni esempi sono:

Zeek (formerly Bro) DNS Query and Response logging per raccogliere e ottenere query e risposte DNS. Utilizzato anche in combinazione con Domain Hotlist.
Snort DNS – Regole che ispezionano le risposte alle query DNS e agiscono in base alla risposta.
Suricata DNS – Regoel per registrare e raccogliere eventi correlati, creare azioni basate su eventi come abbinare query DNS a una blocklist (ad esempio, Domain Hotlist) o scrivere eventi di log per raccogliere query DNS e registrazione delle risposte.

Mail Exchange Server Events
Esistono alcuni casi d’uso per sfruttare i log generati dal proprio server di posta:

Rileva l’infrastruttura di posta elettronica di phishing/spam nota.
- Inviato da infrastruttura di phishing nota o malevola.
- Esempio: “Chiamami al numero 1-888-382-1222 per configurare la tua VPN – Matthew (dal supporto tecnico).”
Rileva collegamenti di phishing/spam noti nel corpo dell’e-mail.
- Contiene collegamenti di phishing, ma è stata eseguita un’azione dell’utente in base agli event log successivi (ad esempio, l’utente fa clic sul collegamento, il dominio su cui viene eseguita la query viene visualizzato nei log).
- Esempio: “Fare clic qui per scaricare il certificato VPN – Matthew (dal supporto tecnico).”
Analizza ulteriormente le indicazioni di phishing ancora sconosciute.

Event Source per i Log di Exchange:

MSExchange Management channel on EventLog (called “MSExchange Management”)
Message Tracking Logs, dove la posizione predefinita è %ExchangeInstallPath%TransportRoles\Logs\MessageTracking

L’MSExchange Message tracking log contiene campi popolati con metadati per la ricerca delle minacce e le indagini DomainTools. Loro includono:

client-ip: l’IP del server/client di messaggistica che ha inviato il messaggio.
client-hostname: l’hostname/FQDN del server/client di messaggistica che ha inviato il messaggio.
server-ip: l’IP del server di origine o di destinazione.
server-hostname: l’hostname/FQDN del server di destinazione.
Un source value field include DNS come origine nota.

L’IP del client e il nome host del client rispondono alle domande “quale infrastruttura ha inviato questo messaggio”, che l’analista utilizza per cercare ulteriori informazioni sull’infrastruttura.

L’IP del server e l’hostname del server è l’indirizzo di destinazione. Questo risponde alla domanda “a chi era rivolto questo messaggio”.

Proactive Defense Note: Utilizzare DomainTools API o la piattaforma di indagine Iris per esaminare ulteriormente le acquisizioni di metadati in questi campi. Un esempio di lavoro con Iris:

Gli hostname vengono estratti dal campo client-hostname dai log di MSExchange.
I domini vengono estratti con il successivo elenco di domini quindi importati in Iris.
Il Domain Risk Score associato a ciascun dominio indica il livello di rischio per quel dominio.
Ulteriori decisioni:
- Correlazione tra il client.hostname e l’IP del server.
- Isolare l’IP del server di destinazione o persino impostare più logging per trovare altri IOC (EventID e altri eventi che potrebbero essere generati per indicare ulteriori compromessi o movimenti laterali).
Aggiunta ad una blocklist, oltre a utilizzare Domain Hotlist.

Windows Firewall Logging
Altre fonti di log che contengono dati IP preziosi includono i log del firewall dal Windows Firewall EventLog Channel.

Proactive Defense Note: utilizzare la Domain Hotlist come blocklist sul firewall della rete.

“Finding Advanced Attacks and Malware With Only 6 Windows EventID’s” di Michael Gough (aka Malware Archaeologist) fornisce ulteriori informazioni sul ciclo di vita di questi EventID che segnalano un attacco. L’Event ID 5156 viene generato quando la Windows Filtering Platform consente a un programma di connettersi a un altro processo (sullo stesso computer o su un computer remoto) su una porta TCP o UDP. I preziosi metadati di questo Event Source indicano il comando e il controllo o l’origine dell’attacco e quale applicazione è stata utilizzata per comunicare con l’indirizzo IP esterno o interno.

Proactive Defense Note: Utilizzare DomainTools Iris Investigate API, Classic Tools API o la piattaforma di indagine Iris per indagare ulteriormente su questo IP. I risultati includono: ricerca di informazioni sull’infrastruttura IP, rivelazione dell’infrastruttura connessa, ricerca di connessioni di questo indirizzo IP, reverse lookup dell’indirizzo IP.

Windows IIS Server Logging

<13>Sep 9 17:38:25 IIS-SERVER 2020-09-09 17:38:25 MALICIOUS_CLIENT_IP_HERE GET /welcome.png - 80 - ::1 Mozilla/5.0+(Windows+NT+10.0;+Win64;+x64;+rv:69.0)+Gecko/20100101+Firefox/69.0 http://localhost/ 200 0 0 11

L’esempio precedente presenta un evento di registro in formato Syslog generato da un server IIS ospitato localmente (test).

Ad esempio, se esiste un numero insolito di richieste da un IP client (indicato da MALICIOUS_CLIENT_IP_HERE), un analista potrebbe voler verificare se l’IP associato è dannoso.

Proactive Defense Note: eseguire un reverse DNS check (ovvero eseguire un controllo per trovare il nome host associato a un IP client). Dal reverse DNS check (per trovare il nome host), controllare l’infrastruttura o il punteggio di rischio o il profilo di minaccia associati su Iris o con l’API.

Sfida
Aumento dei requisiti e dei costi di archiviazione SIEM e LM
Relative ai problemi di infrastruttura sono le sfide di archiviazione e licenza poiché potrebbe essere necessario aumentare la capacità a causa dei requisiti di logging aggiuntivi. Tuttavia, esistono soluzioni per risolverli. Includono il logging mirato (raccolta selettiva solo di determinati EventID o logging channels), la deduplicazione dei log, l’eliminazione dei campi metadati non necessari di un evento di log, batch compression logging e altro ancora.

Altri costi correlati che possono anche aumentare includono:

Costo dell’abbonamento. Questi sono casi in cui l’agente di log o LM/SIEM incorporano costi di abbonamento incentrati sull’inserimento dei dati. Potrebbero esserci utenti o clienti che utilizzano Community Edition o agenti gratuiti con limitazioni di importazione di eventi.
Costo del personale. Gli amministratori o altro personale specializzato potrebbero dover eseguire la distribuzione su istanze o scenari di distribuzione che richiedono la registrazione basata su agenti. Alcuni endpoint richiedono anche lavoro aggiuntivo, ad esempio un endpoint che richiede la configurazione di impostazioni aggiuntive per distribuire la registrazione.

Problemi di infrastruttura relativi alla registrazione
È problematico registrare query e/o richieste a causa di problemi quali il degrado delle prestazioni del server (con il lavoro di elaborazione aggiuntivo richiesto), problemi di archiviazione e altro. In termini di problemi relativi all’elaborazione, ogni volta che si verifica una query o un evento di risposta, il server DNS non solo interpreterà l’evento di telemetria come un’origine del log da raccogliere, ma dovrà anche scrivere gli eventi in un file formato specificato) e quindi inviare a una destinazione esterna. Sono inoltre necessarie analisi aggiuntive o altri arricchimenti che possono fornire maggiori imposizioni relative alle prestazioni sulla risorsa.

I registri devono essere strutturati e normalizzati
I log degli eventi devono essere importati dalla suite SIEM, che ha i propri campi e schemi SIEM. Potrebbero essere necessari moduli e componenti aggiuntivi specialistici aggiuntivi (oltre a quanto offerto dall’agente di raccolta dei registri) per importare e arricchire adeguatamente i registri. Ad esempio, il campo Messaggio nel registro eventi di Windows potrebbe contenere informazioni preziose sull’evento stesso, che deve essere estratto. I log DNS di Linux possono essere scritti in diversi formati, che devono anche essere normalizzati per l’importazione in un SIEM. Questo processo di normalizzazione può aggiungere un ulteriore carico sulle prestazioni.

Il prossimo passo…
…è costruire le configurazioni per raccogliere, analizzare e arricchire gli eventi da queste fonti.

Sebbene sia fuori dallo scopo di questo post coprire il labirinto di impostazioni e configurazioni degli event source per la miriade di piattaforme disponibili, vale la pena ribadire alcuni modi per sfruttarle.

Craft Sigma e altre regole di rilevamento
Sono disponibili regole Sigma che sono già state predisposte per scenari come il rilevamento di server C2 o il rilevamento di un numero elevato di query su un singolo dominio. Le regole Sigma guidano la coerenza nei rilevamenti delle minacce, dopo che una regola Sigma è stata creata, viene quindi condivisa (o convertita) in modo che qualsiasi endpoint che deve utilizzare la regola, come una particolare piattaforma SIEM, possa farlo.

Sono disponibili anche altre risorse per le regole di rilevamento. Esistono altre regole di rilevamento create e condivise online, quindi di seguito è riportato un piccolo elenco:

https://github.com/Azure/Azure-Sentinel/tree/master/Detections/DnsEvents
https://github.com/Neo23x0/sigma/tree/master/rules
- https://github.com/Neo23x0/sigma/tree/master/rules/proxy
- https://github.com/Neo23x0/sigma/tree/master/rules/network
SOC Prime Threat Detection Marketplace (closed, registration only, with Community subscription option). TDM contiene un numero di regole di detection per Sigma, Elastic, Azure Sentinel, CrowdStrike, Splunk, QRadar, PowerShell, Regex, RSA NetWitness, ArcSight, Carbon Black, Sysmon, e molti altri.

Sviluppare con i prodotti API DomainTools
Una copertura efficace degli event source significherà che gli investigatori saranno in grado di trarre il massimo vantaggio da ciò che le integrazioni di DomainTools hanno da offrire. Ad esempio, non limitandosi a fare affidamento sui log proxy quando è possibile anche estrarre un dominio prezioso e altri metadati in altre origini di eventi. Inoltre, i prodotti DomainTools API possono essere utilizzati per sviluppare le proprie integrazioni. Inizia con la documentazione API qui, comprese le query di esempio gratuite.

Usare le integrazioni DomainTools con il proprio SIEM
Oltre alle API, è possibile utilizzare le integrazioni DomainTools per trovare informazioni sulle minacce nei metadati del tuo dominio.

Vai al post originale

Conosciamo il Cyber Insurance MFA Mandate

da Domenico Panetta | Set 22, 2021 | Notizie dal Mercato

La maggior parte delle compagnie assicurative, ora richiede alle organizzazioni di adottare l’MFA per sottoscrivere un’assicurazione Cyber Security.

Nonostante l’aumento della spesa per la sicurezza informatica – quasi 134 miliardi di dollari nello scorso anno – le violazioni dei dati costano alle aziende in media 3,86 milioni di dollari per incidente. Il numero sale alle stelle per coloro che operano in settori fortemente regolamentati e per coloro che si occupano di informazioni sensibili di identificazione personale (PII).

L’ottenimento di un’assicurazione di responsabilità informatica è emersa come una strategia chiave per le aziende per mitigare le perdite e i costi derivanti dagli attacchi informatici. Colonial Pipeline ha già presentato un reclamo alla sua compagnia assicurativa informatica per il riscatto di 4,4 milioni di dollari che ha pagato ai suoi aggressori a maggio. PwC stima che il mercato delle assicurazioni informatiche crescerà fino a raggiungere i 7,5 miliardi di dollari nel prossimo decennio poiché sempre più aziende lo considerano un costo necessario per il proprio business.

Questa rapida crescita, tuttavia, non si è necessariamente tradotta in profitti per i vettori. La portata e i danni dei recenti attacchi, come l’hack di SolarWinds, hanno portato a enormi successi per gli assicuratori informatici. Di conseguenza, le aziende che sottoscrivono o rinnovano polizze possono aspettarsi forti aumenti dei premi, fino al 50% secondo un rapporto di Aon PLC. Possono anche aspettarsi che la maggior parte delle policy richieda l’MFA per qualificarsi per la copertura.

Che cos’è la Cyber Liability Insurance (Assicurazione di Responsabilità Informatica)?

Chiamata più semplicemente assicurazione informatica, copre la responsabilità di un’azienda in caso di violazione dei dati o altri incidenti informatici. Questi tipi di incidenti sono in genere esclusi dalle polizze di responsabilità generale e di proprietà, quindi le organizzazioni che cercano di proteggere i propri dati e risorse richiedono una copertura informatica supplementare o un’assicurazione informatica autonoma.

Ogni polizza assicurativa informatica è diversa e alcune possono differenziare le aree di copertura, ma comunemente affrontano i costi associati a:

Interruzione operativa
Perdita o distruzione di dati
Incident response and investigation
Gestione della crisi
Pagamenti di ransomware o altre richieste di estorsione
Spese legali e difesa

Alcuni possono anche coprire multe e sanzioni associate a GDPR, HIPAA, requisiti di sicurezza informatica del NYDFS e altre normative sulla privacy e sulla sicurezza dei dati.

Comprensione del requisito MFA di assicurazione informatica

La Multi Factor Authentication (MFA) è stata a lungo raccomandata dagli assicuratori informatici come controllo di sicurezza critico data la debolezza intrinseca dei metodi di autenticazione a fattore singolo (es. password). Le organizzazioni con piani per il rinnovo o l’acquisto, tuttavia, stanno scoprendo che la raccomandazione è diventata un mandato.

L’MFA richiede due o più metodi di verifica per consentire agli utenti di accedere a un sistema, dispositivo o applicazione. Nella sua forma più elementare, questo consiste nella password familiare più uno di questi metodi di verifica aggiuntivi:

Conoscenza: qualcosa che conosci, come la risposta a una domanda di sicurezza, un PIN o una password monouso.
Possesso: qualcosa che hai come un token OTP per smartphone o hardware.
Inerenza – Qualcosa che sei, ovvero dati biometrici come un’impronta digitale, un volto o una voce.

L’autenticazione a più fattori rende molto più difficile hackerare un account poiché un utente malintenzionato avrebbe bisogno di più del nome utente e della password, ma anche di controllare il dispositivo utilizzato per l’autenticazione o impersonare i dati biometrici dell’utente, rendendo un attacco più dispendioso in termini di risorse per il malintenzionato.

Perché gli assicuratori richiedono l’MFA?

Fino a poco tempo fa, le aziende potevano ottenere polizze assicurative informatiche senza dover fare i salti mortali. La crescente domanda di assicurazione sulla responsabilità informatica, il numero crescente di richieste di risarcimento e un picco nella gravità delle richieste hanno spinto i sottoscrittori a esaminare più da vicino i controlli di sicurezza di un’organizzazione. La mancanza di adeguate misure di sicurezza informatica può comportare premi più elevati o un rifiuto definitivo.

Il mandato di MFA è una mossa intelligente da parte dei vettori, dato che il mercato delle assicurazioni cyber degli Stati Uniti ha avuto un rapporto di sinistri medio combinato del 103% lo scorso anno, e questo era prima dell’attacco di SolarWinds. Richiedendo l’MFA, gli assicuratori informatici riducono drasticamente la loro esposizione. Il rapporto di indagine sulla violazione dei dati del 2021 di Verizon ha rilevato che le credenziali sono il primo tipo di dato rubato e che le credenziali violate portano al 61% di tutte le violazioni.

Credenziali come password e altri segreti condivisi sono anche il principale vettore di accesso per il ransomware, che lo scorso anno ha rappresentato quasi la metà dei sinistri assicurativi informatici. L’autenticazione a più fattori rende molto più difficile per gli aggressori ottenere l’accesso a un sistema e scatenare ransomware o altri tipi di malware.

Cosa impedisce alle aziende di implementare l’MFA?

Gli esperti di sicurezza hanno battuto per anni il tamburo dell’autenticazione a più fattori, i fornitori di assicurazioni informatiche ora lo richiedono. Allora perché le aziende non hanno implementato l’MFA? I motivi includono:

Costo: include eventuali costi hardware come le chiavi di sicurezza, nonché la loro implementazione e gestione continua, inclusi i costi dell’help desk IT quando gli utenti vengono bloccati o hanno altri problemi di accesso.
Perdita di produttività: richiedere ai dipendenti di utilizzare un fattore aggiuntivo significa che impiegano più tempo per accedere alle applicazioni e ai sistemi di cui hanno bisogno per svolgere il proprio lavoro. In caso di problemi di accesso, ci sono tempi di inattività e sovraccarico dell’helpdesk fino a quando non viene risolto.
Esperienza utente scadente: i lavoratori e i clienti resistono all’adozione di MFA in quanto richiede più passaggi per l’autenticazione.
La riduzione del rischio è insufficiente: l’MFA non è una pallottola d’argento. Molti metodi MFA possono essere aggirati con astuti attacchi di phishing, SIM-swapping, attacchi man-in-the-middle (MitM) e altre sofisticate tecniche di bypass.

È qui che entrano in gioco le nuove tecnologie MFA passwordless. A seconda del tipo di soluzione MFA passwordless implementata, potrebbero non esserci costi hardware oltre agli smartphone che gli utenti già hanno e l’accesso è molto più semplice e veloce persino dell’autenticazione basata su password. Ancora più importante, la vera tecnologia passwordless, in cui né l’utente né il fornitore di servizi possiedono un segreto condiviso o condivisibile, è molto meno vulnerabile agli attacchi.

L’autenticazione passwordless soddisfa i requisiti MFA della Cyber Insurance?

In poche parole, l’autenticazione passwordless sostituisce il fattore basato sulla conoscenza, ovvero la password, con qualcosa che si possiede o qualcosa che si è. L’MFA passwordless richiede molteplici fattori di autenticazione, che si allineano al controllo di sicurezza dell’autenticazione a più fattori richiesto dagli assicuratori informatici.

Tuttavia, le soluzioni MFA passwordless possono variare notevolmente nell’approccio e nei metodi di autenticazione. Alcuni utilizzano ancora una qualche forma di segreto condiviso, rendendoli soggetti alle stesse vulnerabilità delle tecnologie MFA standard. Altri richiedono ancora token di sicurezza hardware, i cui costi sopra menzionati e altri aspetti negativi ostacolano l’adozione dell’MFA. Il vero MFA passwordless segue gli standard di autenticazione stabiliti da FIDO Alliance. L’autenticazione avviene utilizzando il sensore biometrico sul dispositivo o un PIN decentralizzato per sbloccare una coppia di chiavi crittografiche pubblico-private, che viene generata sul dispositivo mobile utilizzando la crittografia asimmetrica. I segreti rimangono al sicuro e con l’utente. Non vengono mai trasmessi o condivisi.

Soddisfa il mandato di MFA di Cyber Insurance in modo indolore

HYPR semplifica l’implementazione di True Passwordless™ MFA nelle organizzazioni e, cosa altrettanto importante, coinvolge gli utenti. L’accesso brevettato avviato dall’utente e una potente architettura certificata FIDO, offrono un accesso semplice e veloce bloccando gli attacchi PUSH e altri tipi di phishing, credential stuffing, brute force, MiTM, replay e attacchi social engineering.

Per scoprire come HYPR aiuta a soddisfare i requisiti MFA di assicurazione informatica, parla con i nostri esperti.

Vai al post originale

Aumentare la visibilità dei server DNS Linux con la log collection

da Domenico Panetta | Set 20, 2021 | How-To, Notizie dal Mercato

Benvenuti nella quarta parte di questa serie di articoli su DNS e domain logging con DomainTools, lo scopo di questo post è concentrarsi sulla Log Collection su Linux e altre piattaforme simili a Unix; sebbene gli ambienti aziendali oggigiorno siano ibridi, piuttosto che completamente omogenei, utilizzeremo questo post per concentrarci su un altro standard di eventi di telemetria: syslog daemon (syslogd) e Syslog message logging.

Questo post inizierà con un esempio di log collection deployment su un server DNS Linux, seguito da una breve panoramica del significato di questi esempi di sorgenti di log e quindi terminerà con l’auditing di Linux. Se si sta lavorando con Windows Event Log di Microsoft, consulta la parte 3 di questa serie, consigliamo inoltre la lettura del primo e del secondo post della serie.

Linux Log Deployment Scenario
Elenco di server DNS che supportano piattaforme Linux/Unix-like:

From Source to SIEM

Aumenta la visibilità dei server DNS Linux con la Log Collection

Di seguito è riportato un esempio di deployment di un server DNS Linux, con un’origine dell’infrastruttura: il BIND9 DNS Server.

From Source (BIND9 DNS Server e auditd Events)

Aumenta la visibilità dei server DNS Linux con la Log Collection

A partire da un BIND9 DNS Server, vengono definite due source principali di telemetria: Auditing Logging Rule e DNS Server Configuration FIle che vengono utilizzati per definire una varietà di regole di logging.

Esempio Source 1: Audit Logging Rules
Questi definiscono le regole per la collection degli auditing log, che possono informare potenziali attacchi all’infrastruttura come modifiche non autorizzate alla configurazione del server DNS. Le modifiche alle autorizzazioni di file o cartelle di attacco nel file di configurazione, l’eliminazione dei log e la disabilitazione del logging sono altre forme di attacchi all’infrastruttura. La mancanza di visibilità di questi eventi costituisce il terreno fertile per gli attacchi di movimento laterale, originati dal server DNS e da altre infrastrutture associate.

Esempio Source 2: DNS Server Configuration FIle
Una parte del file di configurazione del server DNS copre i criteri di logging del server, come ad esempio:

I tipi di eventi DNS da loggare (query only, query e risposta)
Quanto sono dettagliati gli eventi (ad esempio verbose)
I tipi di eventi da raccogliere (come solo eventi warning o tutti gli eventi che vanno da quelli Informational a Warning)

Gli attuali criteri di logging e la configurazione, differiranno per ciascuna implementazione del server DNS. Per BIND9, ecco un esempio di grammatica delle istruzioni di logging dal loro manuale utente:

logging {
  category string { string; ... };
  channel string {
    buffered boolean;
    file quoted_string [ versions ( unlimited | integer ) ]
         [ size size ] [ suffix ( increment | timestamp ) ];
    null;
    print-category boolean;
    print-severity boolean;
    print-time ( iso8601 | iso8601-utc | local | boolean );
    severity log_severity;
    stderr;
    syslog [ syslog_facility ];
  };
};

To SIEM

Aumenta la visibilità dei server DNS Linux con la Log Collection

All’interno del file di configurazione BIND9 DNS, è possibile specificare determinati eventi da scrivere su disco o da inviare tramite flusso TCP/UDP direttamente a un server di gestione dei log. Nel server DNS BIND9, questo è definito nella parte del canale del file di configurazione. Questo informa la destinazione dei messaggi selezionati per il canale: per andare a un file, a una particolare funzione syslog, al flusso di errore standard (stderr) o a null (scartato). Gli eventi in questo esempio di distribuzione, solo gli eventi di sicurezza, vengono inviati al flusso Syslog e scritti su disco (/var/log/security_events.log).

Gli eventi dovrebbero essere scritti in un formato standard. Esistono vari modi per scrivere e trasportare i dati degli eventi. Per Syslog, questi sono BSD Syslog, IETF (implementazione che precede BSD) Syslog, CEF (o Common Event Format, un’implementazione ArcSight), LEEF (Log Event Extended Format, un formato proprietario in relazione a IBM QRadar), Snare Syslog. Esistono anche altri formati accettati, come JSON.

Il modo appropriato per arricchire e scrivere eventi è descritto in dettaglio nella documentazione del proprio SIEM e del Log Collector. Indipendentemente da ciò, l’arricchimento avviene come parte del processo di raccolta dei log sul server DNS e nell’istanza del server di centralizzazione dei log a seconda dei requisiti di distribuzione. Potenzialmente sul SIEM, gli eventi possono essere consumati e presentati come eventi “raw” se non sono stati correttamente arricchiti. Potrebbero esserci anche regole aggiuntive per instradare questi log poiché non tutti potrebbero avere un valore di sicurezza immediato, come i log a scopo di debug.

Dal lato SIEM, è necessario lavorare ulteriormente per arricchire i log per l’analisi, le regole di automazione e altro ancora. Ad esempio, deve essere chiaro che esiste una coppia chiave-valore per i metadati del dominio poiché costituisce la base per DomainTools App for Splunk e l’origine dei metadati dovrebbe essere rilevante indipendentemente dall’origine della piattaforma.

Esempio di BINDDNS Server Event

Informazioni su BIND9 DNS Server
BIND9 è un software open source DNS ampiamente utilizzato, BIND9 è attualmente mantenuto dall’ISC (Internet Systems Consortium). Il software BIND9 include un Domain Name Resolver che risolve le query sui nomi comunicandole ai server appropriati e rispondendo alle replies dei server. Il BIND9 Domain Name Authority server, risponde alle richieste dei resolver. Di seguito è riportato un esempio dal Resolver.

Esempio BIND9 named.conf
I file di configurazione per il logging di BIND9 coprono come, cosa e dove. Di seguito è riportato un esempio per il logging delle query in un file.

logging {
        channel query {
                file "/var/log/queries.log";
                print-severity yes;
                print-time yes;
        };
       category queries { query };
};

Snippet del resolver BIND9 DNS
Come messaggio di log semistrutturato, di seguito è riportato un log di esempio da un ambiente di test per query example.com:

30-May-2020 11:11:11.553613 queries: info: client @0x7f39604b8660 127.0.0.1#50587 (example.com): query: example.com IN A +E(0)K (127.0.0.1)

Sebbene quanto sopra sia leggibile dall’uomo, non è necessariamente consumabile nel proprio SIEM e può essere presentato come un log non elaborato e non utilizzabile per ulteriori elaborazioni. Con il parsing e l’arricchimento in corso, il messaggio non strutturato viene suddiviso in questo tipo di coppia valore-chiave:

EventTime: 2020-05-30T11:11:11.533613+01:00
Category: queries
Severity: info
Client: 127.0.0.1#50587
Address: 127.0.0.1
Query: example.com
Type: A
Class: IN
Flags: +E(0)K

Pertanto, i metadati che risiedono in campi importanti, come nel campo Query, hanno valore per un’ulteriore elaborazione. Ad esempio, una delle integrazioni DomainTools ruota attorno alla capacità di elaborare domini che sorgono all’interno del perimetro della rete. In tal caso, si desidera che ogni query venga elaborata come parte di questo lavoro poiché, dopo tutto, fa parte di un evento che si è verificato nel perimetro. Inoltre, si potrebbe notare che il timestamp dell’evento è già impostato per accedere a timestamp ad alta precisione e non solo, EventTime è nello standard ISO8601, con millisecondi e fuso orario aggiunti alla fine (UTC+01:00), per garantire coerenza e precisione nei timestamp.

Linux DNS Audit Logging
Applicare l’audit logging al proprio server DNS per tenere traccia degli eventi rilevanti per la sicurezza. L’applicazione delle regole di logging dei controlli, consente di tenere traccia di eventi di sicurezza più mirati. Sapere di più sul sistema di controllo nella propria piattaforma è utile quando si impostano le regole di logging dell’audit e si leggono gli eventi, di seguito è riportato un esempio.

Esempio BIND9 Linux Audit Logging:
Si consiglia di consultare la documentazione della propria piattaforma per le auditing rules (se non se ne ha una a portata di mano, è possibile fare riferimento alla RHEL documentation on Linux Audit Logs).

Per guardare /etc/bind/ per le modifiche e aggiungere un tag:

-w /etc/bind/named.conf -p wa -k conf-change-bind9

Lo snippet del risultato nel formato delle coppie chiave-valore (non raw log):

type: CONFIG_CHANGE
UID: 0
comm: nano
exe: /bin/nano
Key: conf-change-bind9
EventTime: 2020-05-30T12:19:20.055718+01:00

Viene aggiunta una regola per controllare /etc/bind per creare i log in caso di accesso in scrittura e ogni modifica di attributo del file named.conf nel server BIND9. Quando questo viene osservato, viene registrato un log con il tag conf-change-bind9.

Lo snippet del risultato dovrebbe essere leggibile dagli utenti. CONFIG_CHANGE è il tipo di record di audit osservato. Il codice uid, che è 0, indica che era un account di superuser che ha modificato il file di configurazione con l’editor nano (e invocando il comando nano).

Quando è impostata l’audit logging per questi e altri eventi, l’amministratore può fare riferimento alla documentazione della propria piattaforma per leggere le regole di audit. Si può anche osservare il trail dei log di audit; ad esempio, possono vedere quale utilità è stata utilizzata per modificare il file di configurazione.

Domande finali
Con questo post, abbiamo presentato un esempio di deployment di una collection di log BIND9 DNS su una piattaforma Linux/Unix like, con un evento di esempio e, sia un evento resolver che un evento di auditing di una modifica alla configurazione del server. Sentiti libero di tornare all’inizio e verificare se la tua distribuzione ha coperto quanto segue:

Quali informazioni di monitoraggio su DNS e domain activity possono essere ottenute dalle source esistenti?
Quali aree devono essere ampliate per migliorare la visibilità dei log, in particolare per i metadati contenenti log di dominio e DNS?
Quali altre opportunità ci sono per aumentare l’ambito complessivo della raccolta dei log?
Quale di queste source porta a una migliore intelligenza per i tuoi casi d’uso?
L’attuale log deployment soddisfa le esigenze della fase finale in termini di informazioni per la threat hunting, incidence response, orchestration, automation, ecc.

Sebbene non sia possibile approfondire i dettagli del deployment effettivo (come più esempi di configurazione, logging DNSSEC e altro), è possibile controllare la documentazione della piattaforma e del server DNS, nonché il proprio Collector e la documentazione SIEM, per vedere quali configurazioni devono essere applicate e quali opzioni sono disponibili.

Utilizza le integrazioni e le API di DomainTools per arricchire ulteriormente gli eventi rilevanti con DNS e domain intelligence (Domain Risk Score), oltre a utilizzare gli IOC di dominio con la piattaforma Iris. Usa DomainTools come parte della tua difesa proattiva e reattiva, oltre al logging mirato.

Vai al post originale

Come scegliere il giusto SIEM, 8 criteri per una valutazione su misura

da Domenico Panetta | Set 15, 2021 | How-To

Per comprendere l’esperienza dei team di Sicurezza IT, inondati quotidianamente da eventi e log di ogni tipo, senza avere il tempo necessario per un’analisi approfondità e per assegnare la giusta priorità, basta immaginare di avere un orologio a cucù, ma che invece di suonare ogni ora, suoni ad ogni minuto. Non solo il verso del cuculo diverrebbe un rumore di fondo, ma si avrebbe anche difficoltà a sapere che ore sono.

Le soluzioni di Security Information and Event Management (SIEM), aiutano a fornire questa analisi semplificata e la definizione delle priorità, consentendo di reagire rapidamente e con precisione, alle minacce più insidiose, fornendo preziose informazioni sulle potenziali minacce alla sicurezza, attraverso la raccolta e l’analisi centralizzata dei log e degli eventi di sicurezza, provenienti da tutti i dispositivi presenti all’interno di una infrastruttura e già normalizzati.

Ma come capire come scegliere il SIEM più idoneo al proprio ambiente di sicurezza? I SIEM differiscono ampiamente in termini di funzionalità, quindi è importante determinare con attenzione quali siano le funzionalità chiave di cui abbiamo bisogno.

Monitoraggio e alert in tempo reale
Questa è una funzionalità prioritaria e fondamentale per tutte le organizzazioni. La capacità di monitorare e correlare le minacce in tempo reale può fare la differenza tra un piccolo inconveniente e costose conseguenze dovute ad una interruzioni dei servizi. I pirati informatici si muovono velocemente, quindi il team di sicurezza deve potersi muovere e reagire altrettanto rapidamente.
Analisi del comportamento degli utenti
Che si tratti di malizia o errore, gli utenti sono il principale veicolo di minaccia all’interno di qualsiasi infrastruttura IT, in particolare quando si tratta di un utente privilegiato. Il monitoraggio delle attività degli utenti (non a scopo di controllo), può permettere di rilevare velocemente una violazione o scoprire usi impropri ed errori, oltre che, nel caso di utenti privilegiati, essere un requisito fondamentale di conformità.
Indagini
Le indagini sugli incidenti non sono facili quando ci si trova di fronte a una montagna di avvisi e log. A volte, tutto ciò di cui si ha bisogno, è una risposta rapida e che evidenzi automaticamente il comportamento importante di utenti e risorse, insieme al contesto attorno a qualsiasi comportamento dannoso, sopratutto dal punto di vista temporale. Le indagini sono un aggregato degli avvisi critici, analizzabili in un unico luogo, alle quali verranno aggiunti ulteriori nuovi avvisi correlati, anziché creare una nuova indagine.
Rilevamento delle minacce nell’ambiente
Le organizzazioni spesso dispongono di una moltitudine di tecnologie diverse, ognuna per il proprio ambito. Un SIEM dovrebbe essere in grado di normalizzare e correlare tutti questi diversi flussi di dati in un formato comune e dargli un significato, ben più di ciò che fa un semplice log aggregator. A prescindere dal Sistema Operativo o dal brand, un SIEM dovrebbe essere in grado di elaborare correttamente tutti i log necessari, e non dovrebbe essere limitato alle sole origini dati standard, ma a ogni origine all’interno dell’ambiente di un’organizzazion, oltre che essere in grado di integrare facilmente qualsiasi feed personalizzato, dalle applicazioni legacy ai database fatti in casa.
Archiviazione di eventi a lungo termine
L’archiviazione dei log richiede molto spazio, e con dispositivi che trasmettono costantemente log, si avrà bisogno di un SIEM con spazio sufficiente per non dover rinunciare a informazioni per eseguire una corretta analisi indietro nel tempo o anche solo per conformità che richiede l’archiviazione a lungo termine dei dati. Una soluzione efficace dovrebbe inoltre consentire di personalizzare esattamente i tipi di dati che si desidera archiviare, escludendo i dati non necessari.
Scalabilità
Le organizzazioni non sono statiche, allo stesso modo non dovrebbe esserlo una soluzione SIEM, che dovrebbe consentire un veloce e semplice adattamento alle innovazioni tecnlogiche. Molte soluzioni SIEM concedono in licenza la quantità di dati elaborati (Eventi Per Secondo o EPS), che non solo è difficile da stimare, ma può anche far aumentare drasticamente e rapidamente i costi. Una soluzione SIEM che conceda licenze su una misurazione più prevedibile, come numero di dispositivi o fonti di dati, permette una pianificazione dei costi precisa e con largo anticipo, evitando spiacevoli sorprese nei costi di licenza. Le organizzazioni più piccole potrebbero persino essere in grado di ottenere la copertura di cui hanno bisogno da un SIEM, permettendo una crescita graduale man mano che l’organizzazione cresce.
Integrazioni
Per quanto ci si metta d’impegno, la nascità di nuove esigenze, di funzionalità o anche solo di costi di licenza, richiederà di destreggiarsi tra un eccesso di prodotti chiusi che non possono comunicare tra loro. Una soluzioni SIEM dovrebbe poter ottenere dati da altre applicazioni aziendali (endpoint protection, log di accesso, firewall etc etc). Questo non solo consente di risparmiare tempo aggiuntivo e costi per gestire le integrazioni, ma fornisce anche un’immagine olistica del proprio ambiente.
Segnalazione
Tutti i team IT, sopratutto quelli di sicurezza, sono tenuti a fornire regolarmente rapporti sia ai revisori che ai dirigenti, spessevolte per conformarsi a più normative, aumentando la complessità e lo sforzo di reporting. Un’adeguata soluzione SIEM deve essere in grado di fornire report rilevanti e in poco tempo.

Stai cercando una soluzione SIEM che rispetti questi 8 criteri? Guarda in azione InsightIDR di Rapid7, oppure contattaci per un approfondimento e una demo dedicata.

Massimizzare le difese con la log collection DNS in Windows

da Domenico Panetta | Set 13, 2021 | How-To, Notizie dal Mercato

Massimizzare le difese tramite DNS Logging
Lo scopo di questo post, terzo della serie, è di introdurre alla raccolta dei log sulla piattaforma Microsoft Windows. Inizieremo con un’illustrazione di una distribuzione di log solo origine Windows, seguita da una raccolta di campi scelti da esempi di log e una breve descrizione di queste origini. L’ultima parte riguarderà l’audit logging, poiché svolge un ruolo importante nel garantire la difesa dell’infrastruttura.

Prima di continuare, raccomandiamo la lettura del primo e del secondo post di questa serie.

Windows Log Deployment Scenario
Per iniziare le indagini trattate nella seconda parte di questo post, gli analisti e i soccorritori devono essere armati con i relativi log DNS e di dominio, dando loro così visibilità sugli eventi rilevanti che si verificano sulla rete. L’organizzazione potrebbe già implementare una forma di registrazione centralizzata su una scala simile a quella mostrata di seguito. In caso contrario, c’è sempre spazio per miglioramenti!

Dalla sorgente al SIEM

Massimizzare le difese con Windows DNS Logging

Sul lato sinistro sono indicati possibili fonti di log, è stata definita una piccola parte di una distribuzione di log di esempio, anche se il numero effettivo di endpoint di origine log univoci è molto più di quanto illustrato qui. Quindi, mentre ci spostiamo a destra del diagramma, vediamo come i log possono essere inoltrati a un server di gestione dei log o a un data lake, quindi a un SIEM per ulteriori azioni.

Da questi Event Source…

Massimizzare le difese con Windows DNS Logging

Il lato del diagramma “Source” a sinistra, illustra alcune potenziali sorgenti di eventi. Un computer client viene mostrato per rappresentare che ci sono eventi che si verificano client-side che devono essere raccolti ed è stata aggiunta l’etichetta per mostrare alcuni esempi dei tipi di eventi da raccogliere, come gli eventi generati da Windows Sysinternals System Monitor (Sysmon), eventuali subscription a EventID di alto valore e canali. Esistono anche altre log source che non utilizzano la telemetria del Windows Event Log, come il loggin file-based e altre log source che sono raggruppate nell’area “other predefined collection processes” come (rappresentati nelle icone) Windows firewall, Powershell logging, ingress logging.

Ci sono tre server che sono stati definiti in questo esempio:

Un server di posta in sede, il server Exchange: È impostato per raccogliere gli Exchange Message Tracking Logs che, nei metadati, contengono informazioni su IP e nome host.
Il server DNS di Windows: La raccolta dei log è impostata sul canale DNSServer Windows EventLog Analytic, così come l’audit logging. La raccolta può anche essere abilitata e configurata manualmente per raccogliere gli eventi del registro DNS debug.
Il server Active Directory: Questo server è un obiettivo di alto valore per molti motivi. La raccolta dei log è configurata per raccogliere i log GPO o Group Policy Object, nonché gli Audit log.

Esistono molte altre origini di log che forniscono informazioni preziose per le indagini e le integrazioni di DomainTools, come i log provenienti da eventi del firewall, Windows IIS server log, i tentativi di autenticazione in ingresso e altro ancora. È anche possibile distribuire una baseline di raccolta e un’opzione per abilitare la raccolta baseline sospetta che comporterebbe una raccolta più dettagliata di una macchina di destinazione sospetta.

…al SIEM per integrazioni, automazione e analisi

Massimizzare le difese con Windows DNS Logging

Le Windows subscriptions possono essere distribuite per estrarre solo eventi di Windows EventLog (tramite WEF, Windows Event Forwarding). Da queste origini client/server, tali eventi vengono inoltrati a un Windows Event Collector.

Un altro collector, fornito dal SIEM o da una terza parte, verrà inoltre distribuito per raccogliere più eventi, espandere la visibilità e garantire che altri tipi di log non vengano lasciati indietro, come i log file-based.

Questi eventi possono essere eventualmente inoltrati a un data lake o a un server di gestione dei log. Tutti i log non arrivano a un SIEM per motivi quali i costi di archiviazione, infrastruttura e licenza, e anche perchè non tutti gli eventi potrebbero avere un caso d’uso supportato da SIEM.

Il processo di normalizzazione dei log è importante, poiché le voci non sono scritte in un formato standard. Oltre a normalizzare i log, vengono applicati l’analisi e l’arricchimento di questi eventi. Questi processi vengono eseguiti durante il transito dal collector e/o sul disco della sorgente stessa o sul server di gestione dei log.

Una volta che i log raggiungono il SIEM, vengono utilizzati per integrazioni aggiuntive, per fornire qualsiasi altra azione da eseguire (triaging), arricchire l’analisi, attivare avvisi e così via.

Windows Event Log
Finora abbiamo coperto un esempio di distribuzione dei log. Di seguito sono riportati i campi di esempio dei log di Windows DNS selezionati per dare un’idea dei tipi di informazioni fornite. Da notare che questi sono già arricchiti/scritti in un altro formato e sono solo frammenti e non il log completo.

Windows DNS Client Sources
Gli event source specifici di Windows DNS Client per gli eventi DNS includono:

Windows Event Log channels (DNS Client Events – Operational)
Sysmon Event ID 22 DNSQuery
Event Tracing for Windows (Microsoft-Windows-DNS-Client ETW Provider)

Esempio di DNSQuery con Sysmon Event ID

“Hostname”: “sld.tld.”
“Severity”: “INFO”
“EventID”: 22
“Source”: “Microsoft-Windows-Sysmon”
“ProviderGuid”: “{5770385F-C22A-43E0-BF4C-06F5698FFBD9}”
“Channel”: “Microsoft-Windows-Sysmon/Operational”
“Domain”: “NTAUTHORITY”
“AccountName”: “SYSTEM”
“UserID”: “S-1-5-18”
“AccountType”: “User”

Nell’esempio sopra, possiamo vedere che questo evento proviene da un’istanza chiamata “sld.tld”. Poiché conosciamo l’origine di questo evento, è quindi utile per trovare la fonte nel caso in cui venga eseguita un’indagine per IR. Anche i campi per Domain, Account Name e security identifier (SID) (o UserID S-1-5-18) possono essere utili.

“Message”:
Dns query:
RuleName:
UtcTime: 2020-10-29 11:32:43.274
ProcessGuid: {b3c285a4-5f1e-5db8-0000-0010c24d1d00}
ProcessId: 5696
QueryName: example.com
QueryStatus: 0
QueryResults: ::ffff:93.184.216.34;
Image: C:\\Windows\\System32\\PING.EXE

Incluso negli eventi di Windows c’è il campo Message. Dal campo Message (che era stato analizzato qui), possiamo vedere che l’evento Sysmon Event ID 22 DNSQuery è stato emesso a causa del comando ping utilizzato con example.com.

Che cos’è un’applicazione di esempio del Sysmon Event ID 22 loggin?
Supponiamo che example.com sia un link di grande interesse. Una delle funzionalità dell’app è arricchire i risultati con un Risk Score, e in questo caso, example.com ha ottenuto un Risk Score elevato di 90. Con i log raccolti, è possibile risalire a data, ora, nome host, account, il programma di utilità e così via. Ulteriori azioni di risposta agli incidenti, come la ricerca della fonte di origine, possono aiutare con le misure di isolamento/contenimento di un’istanza, oltre a fornire un caso d’uso per iniziare una registrazione più ampia come macchina mirata. Supponendo che vengano raccolti 600 milioni di eventi al giorno, isolare tali incidenti in un intervallo di tempo specifico può anche aiutare a ridurre MTTD/MTTR per ottenere e trovare altri EventID IOC.

Ulteriore lettura:
Sono disponibili ricerche interessanti su Evading Sysmon DNS Monitoring e Using Sysmon and ETW For So much more on Binary Defense, che contiene una sezione sullo sfruttamento degli eventi DNS e Sysmon.

Windows DNS Server Source

Le origini degli eventi del server DNS sono:

Event Tracing for Windows (Microsoft-Windows-DNS-Server-Service, Microsoft-Windows-DNSServer ETW Providers)
DNS Debug log file
Windows Event Log channels

ETW/Windows DNS Service Provider Source
Quello che segue è uno snippet dal canale Microsoft-Windows-DNSServer/Analytical channel for Event ID 260. È solo una parte di un esempio di traccia degli eventi in key-value pairs.

“Source”: “Microsoft-Windows-DNSServer”
“ProviderGuid”: “{EB79061A-A566-4698-9119-3ED2807060E7}”
“EventId”: 260
“Severity”: “INFO”
“Domain”: “NT AUTHORITY”
“AccountName”: “SYSTEM”
“UserID”: “S-1-5-18”
“AccountType”: “User”
“TCP”:”0″
“Destination”: “destination.IP”
“InterfaceIP”: “interface.IP”
“RD”: “0”
“QNAME”: “subdomain.sld.tld”
“QTYPE”: “28”
“XID”: “17271”
“Port”: “0”
“Flags”: “0”
“RecursionScope”: “.”
“CacheScope”: “Default”
“PolicyName”: “NULL”
“BufferSize”: “76”
“PacketData”: “0x437700000001000000000001096C6F63616C686F73740975732D656173742D320D6563322D7574696C697469657309616D617A6F6E61777303636F6D00001C00010000290FA0000080000000”

QTYPE significa che era un record A, un indirizzo IP.
QNAME: proviene dalla nostra istanza.
AAAA: 28 indica un record di indirizzo IPv6 a 128 bit. Più comunemente utilizzato per mappare i nomi host a un indirizzo IP dell’host.

Se si effettua un confronto tra l’EventID 260 e il WireShark DNS request packet per lo stesso evento, si noterà che gli stessi campi vengono acquisiti nel payload DNS rispetto al testo completo dell’evento (es. PacketData, QNAME, DestinationIP, etc.).

Esistono anche altre fonti per ETW per registrare altri eventi rilevanti. Da F-Secure Consulting nei loro laboratori si nota un altro provider ETW, Microsoft-Windows-WebIO, che fornisce agli analisti la visibilità delle richieste Web effettuate da alcuni processi di sistema.

Informazioni sul ETW/Windows DNS Service Provider
In breve, ETW ha quattro componenti principali che sono:

Provider: un fornitore di informazioni per la traccia degli eventi per le sessioni di Windows.
Sessione: una raccolta di buffer in memoria che accettano eventi tramite l’API del provider ETW di Windows.
Controller: avvia e arresta le sessioni ETW.
Consumatore: riceve gli eventi dalla sessione ETW da un file di registro.

ETW contiene una preziosa fonte di telemetria di Windows. Non rientra nell’ambito di questo post, ma è possibile saperne di più su Windows DNS ETW nel portale della documentazione.

Windows DNS Server Debug
Di seguito è riportato un esempio di frammento di prova dal Windows DNS Debug Log File. Questo tipo di logging dovrebbe essere eseguito solo in un lasso di tempo temporaneo, a causa della sua natura dettagliata che influisce sulle prestazioni del server, tra gli altri potenziali problemi. I log devono essere analizzati per estrarre i metadati rilevanti (come l’indirizzo IP o il protocollo) come parte della raccolta dei log. Questo esempio è stato aggiunto per mostrare come i registri grezzi da soli non siano sicuramente pronti per l’uso e richiedono un ulteriore arricchimento per essere utilizzabili.

10/30/2020 8:16:54 PM 0FC0 PACKET 000001E1A286DE90 UDP Rcv 172.31.21.66 16df Q [0001 D NOERROR] NS (0)
10/30/2020 8:16:54 PM 0FC0 PACKET 000001E1A34544B0 UDP Rcv 199.7.83.42 de78 R Q [0084 A NOERROR] NS (0)

DNS Server Shutdown Event Snippet in XML
Di seguito è riportato un frammento del Windows DNS Shutdown Event in XML View dal Windows Event Viewer. Sebbene si tratti di dati strutturati, è possibile vedere come si discosta da un formato di dati che può essere utilizzato in un altro sistema, come un SIEM. È necessario un connettore event source come un connettore diretto, un modulo di input o un log agent per normalizzare l’XML.

<Provider Name=”Microsoft-Windows-DNS-Server-Service” Guid=”{71a551f5-c893-4849-886b-b5ec8502641e}” />
<TimeCreated SystemTime=”2020-09-23T21:33:21.512036500Z” />
<Channel>DNS Server</Channel>
<Computer>ec2-xx-xxx-xxx-xx.us-east-2.compute.amazonaws.com</Computer>
<Security UserID=”S-1-5-18″ />
</System>
<EventData Name=”DNS_EVENT_SHUTDOWN” />
</Event>

Window Auditing Logs
La discussione sulla raccolta di log che coinvolge DNS non è completa finché non includiamo anche la registrazione di controllo sull’infrastruttura DNS. La registrazione dell’audit non solo aiuta a soddisfare gli obiettivi di verifica e conformità, ma fornisce anche i dati degli eventi ai difensori per aiutare i soccorritori a ottenere maggiori informazioni su un attacco all’infrastruttura DNS. La registrazione del server, serve anche per qualsiasi altro problema operativo e di risoluzione dei problemi che coinvolge l’infrastruttura.

Queste fonti di eventi includono:

Windows Enhanced DNS server auditing events (Windows-DNSServer/Audit channel – Windows DNS Logging and Diagnostics – Audits events)
Windows DNS server analytic events (vedi la pagina Windows DNS Logging and Diagnostics – Analytic events)
Microsoft Active Directory (vedi AD Events to Monitor resource and Microsoft Audit Policy recommendations)
Microsoft DNS Windows Group Policy logging (vedi DNS Windows Group Policy settings associated with the DNS Client service)

Opzioni di Windows DNS Event Logging migliorate
L’origine di questi eventi include il canale Microsoft-Windows-DNSServer/Audit EventLog e l’Event Tracing Windows provider. I tipi di eventi trattati nella registrazione di controllo sul server DNS includono:

Cache operations—Purging a cache.
DNSSEC operations—Key rollover events, export/import DNSSEC, trust point related events.
Policy operations—Events for the client subnet record, zone level policy, forwarding policy, client subnet record were created, deleted, or updated.
Server operations—Restarting server, clearing of debug logs, clearing of statistics, changes to listen events.
Resource record updates—Resource Record (RR) creation events such as deletion or that a record was modified.
Zone operations—The zone was deleted or updated, a zone scope was deleted or updated.

Domande finali
Nota: un elemento che si potrebeb notare dal diagramma “Source to SIEM” è che sono stati inclusi sorgenti di log che non sono trattate in questo post, ad esempio i log di Exchange così come i log di altri processi di raccolta. Ne parleremo un po’ più in dettaglio nel post finale di questa serie.

Con questo post, ci siamo introdotti in una distribuzione di Windows log collection di esempio, i tipi di eventi che possono essere raccolti su Windows DNS Server e clint e sui tipi di log. Si consiglia tornare all’inizio e verificare se la propria distribuzione ha coperto quanto segue:

Quali informazioni di monitoraggio su DNS e attività del dominio possono essere ottenute dalle fonti esistenti?
Quali aree devono essere ampliate per migliorare la visibilità dei log, in particolare per i metadati contenenti log di dominio e DNS?
Quali altre opportunità ci sono per aumentare l’ambito complessivo della raccolta dei registri?
Quale di queste fonti porta a una migliore intelligence per i propri casi d’uso?
L’attuale log deployment, soddisfa le esigenze della fase finale in termini di informazioni per la ricerca delle minacce, risposta all’incidenza, orchestrazione, automazione, ecc.

Sebbene non sia possibile approfondire i dettagli della distribuzione effettiva (come esempi di configurazione o istruzioni su come abilitare la registrazione di controllo), è possibile controllare la documentazione Microsoft, nonché il proprio agente di registro e la documentazione SIEM per vedere quali configurazioni devono essere applicati e quali opzioni sono disponibili.

Utilizzate le integrazioni e le API di DomainTools per arricchire ulteriormente gli eventi rilevanti con DNS e domain intelligence (Domain Risk Score), oltre a utilizzare gli IOC di dominio con la piattaforma Iris. Usare DomainTools come parte della propria difesa proattiva e reattiva, oltre alla registrazione mirata.

Vai al post originale

Come la Log Collection rafforza le difese con DomainTools

da Domenico Panetta | Set 9, 2021 | How-To, Notizie dal Mercato

In questo secondo post della serie “Log Collection”, ci concentreremo sulla relazione e il ruolo della log collection dei metadati con sicurezza difensiva (squadra blu/viola) tramite DomainTools, aiutando a considerare il lavoro di ricerca condotto in precedenza.

Nel primo post della serie, abbiamo menzionato diverse guide alla log collection, inclusa l’NSA, queste configurazioni e pubblicazioni nascono solitamente dalla ricerca sulla difesa, completando il ciclo di vita dalla ricerca offensiva, alla difesa, per poi tornare agli implementatori dei sistemi SIEM e di telemetria; l’NSA ha pubblicato il rapporto Spotting the Adversary, ad esempio, e JPCERT (Coordination Center) in Giappone ha analizzato quali log di eventi erano dovuti a strumenti malware noti, come Windows EventID 5156, che indica un nuovo evento di connessione di rete, e abbiamo anche coperto un esempio di log deployment, ma analizzando solo i numeri, per darci un’idea della scala della raccolta di telemetria in un ambiente aziendale.

Log Source e MITRE ATT&CK
La mancanza di un approccio mirato ai log di sicurezza, può portare a problemi di prestazioni da parte degli agenti di log, eccessivi costi di licenza SIEM e agent e costi di sottoscrizione, eccessivi requisiti di infrastruttura, rumore di fondo e alert, insufficiente log colelction e altro. OWASP ha anche consigliato di non raccogliere troppi log (così come troppo pochi) come best practice per l’implementazione del log di sicurezza. Oltre a seguire la guida e le risorse del post inaugurale di questa serie, un’altra squadra blu e pratica difensiva è quella di mappare le fonti di log con framework come MITRE ATT&CK per garantire che i dati di log elevino la caccia alle minacce, e le operazioni di sicurezza possano configurare migliori avvisi e regole di triage.

Cos’è il Framework MITRE ATT&CK
MITRE ATT&CK® è una base di conoscenza accessibile a livello globale di tattiche e tecniche avversarie basate su osservazioni del mondo reale. Sopra c’è uno screenshot della matrice MITRE ATT&CK Navigator v4.0 for Enterprise, disponibile anche su Github.

Specifiche tattiche MITRE ATT&CK
Le seguenti sono fonti di log che si riferiscono a una tattica MITRE ATT&CK. Questi log sono specifici per i casi d’uso che DomainTools copre per Iris, PhishEye e API come:

Trovare IOC di dominio tramite Risk Score, Threat Profile o investigation sulla piattaforma web Iris.
Trovare metadati preziosi, come indirizzi e-mail o termini chiave per le indagini sulla piattaforma web Iris.
Utilizzo delle API, come la Reverse IP API, per trovare i domini associati a un indirizzo IP.

Quali fonti devono aggiungere i difensori nell’ambito della log collection?
Tattica: Command&Control (C2)

Tattica: Exfiltration (Exfiltration over C2, Over Alternative Protocol)

Le richieste DNS mostrano tentativi di risolvere domini dannosi noti o tentativi di contattare domini con una cattiva reputazione.
I log del perimetro di rete mostrano l’esfiltrazione verso un indirizzo IP esterno.

Fonti di log correlate: Linux DNS query logs, Windows Sysmon DNSQuery logs, DNS protocol packet capture logs, Windows Firewall logs, etc.

Tattica: Defense Evasion

Tecnica “Impairment of Defence”

Server DNS utilizzato in modo dannoso (generazione di nomi di dominio falsi, squatting, attacchi alle infrastrutture).
Il server è stato modificato, ad esempio la modifica delle autorizzazioni al flusso di output di Syslog o al file di output per non consentire il logging o la modifica della configurazione del server DNS stesso per disabilitare il logging.
Manomissione del sistema per disabilitare il logging di PowerShell (nel senso di disabilitare il meccanismo di traccia degli eventi Powershell in Windows).

Fonti di log correlate: Group Policy Modification (Windows GPO) logs, Windows PowerShell logs to find suspicious PowerShell commands (disable of PowerShell event trace), Linux auditing logs (configuration file changes).

Tattica: Persistence Mechanism

Configurazione della persistenza su un server DNS per attività backdoor malware in un secondo momento, come la connessione successiva a un server C&C.

Fonti di log correlate: Le sorgenti di log sono simili a Exfiltration e alle tattiche C2.

Credential Access (T1171)

Successo e insuccesso delle autenticazioni in ingresso, inclusi i tentativi di accesso di una minaccia interna nota nell’azienda.

Log correlati: autenticazioni in ingresso e tentativi di accesso al perimetro della rete.

Caccia post-sfruttamento con i log: Mimikatz, uno strumento per il furto di credenziali
I seguenti sono tipi di esempi di sorgenti di log* per rilevare un attacco Mimikatz, ma sono più correlati ai log che mostrano i metadati relativi a DNS, IP e dominio:

Windows Sysmon Logs
- Sysmon è uno strumento di utilità che offre una capacità di log collection robusta ed estesa. Ad esempio, è possibile configurare Sysmon per aiutare il logging del trail degli strumenti di utilità che gli aggressori utilizzano con il Sysmon process logging.
- È inoltre possibile utilizzare Sysmon per raccogliere eventi DNSQuery, eventi FileDelete, eventi correlati a WMI (Strumentazione gestione Windows) e altro ancora.
Windows PowerShell Event Log a Logging via
- PowerShell è uno strumento di utilità comune utilizzato per automatizzare le attività in un ambiente Windows. La stessa origine eventi di PowerShell può essere presa di mira, ad esempio gli aggressori che disabilitano la traccia Windows PowerShell ETW Event Provider.
- È possibile non solo il logging degli eventi di Windows di PowerShell (tramite Windows Event Log o Event Tracing per Windows), ma anche il logging di PowerShell, che può essere abilitato tramite le impostazioni GPO.
- Lo script Invoke-Mimikatz viene loggato tramite canale Microsoft-Windows-PowerShell/Operational (da JPCERT CC), nonché il Destination IP address/Hostname/Port number in caso di successo.
Windows DNS Analytical Logging
- Fonte molto dettagliata dei log DNS, che contiene dati molto dettagliati delle informazioni DNS inviate e ricevute dal server DNS. Disponibile da Windows Server DNS (2012R2 in poi con questo hotfix).
Windows DNS Analytical Logging
- Tipo di eventi “Informational” disponibile da Windows Server DNS (2012R2 in poi con questo hotfix). I tipi di eventi includono eventi RESPONSE_SUCCESS che contengono l’indirizzo IP di destinazione, QNAME (o il Query Name like example.com).

*Questi esempi provengono dalla ricerca “Hunting for Post-Exploitation Stage Attacks with Elastic Stack and the MITRE ATT&CK Framework“. DomainTools possiede l’integrazione Elastic App per fornire una migliore comprensione delle minacce nella rete utilizzando i log raccolti dai proxy.

Trovare gli aghi (metadati) nel pagliaio
Anche dopo la raccolta della sorgente di log, c’è ancora la sfida di elaborare (strutturare, estrarre, arricchire) i preziosi metadati all’interno di questi log. L’analisi dei metadati avvantaggia le operazioni di sicurezza perché porta a regole più mirate (per dashboard, search index o per filtrare le indagini), alert o per utilizzare i dati per ulteriori analisi su come indagare sugli IOC di dominio all’interno del proprio SIEM/SOAR.

Quali sorgenti di log rivelano l’esfiltrazione di IP/Hostname?
Diamo un’occhiata a un paio di fonti di log menzionate in precedenza nella sezione MITRE ATT&CK Tactics. In questo caso, esaminiamo la tattica Exfiltration MITRE e vediamo quali fonti di log sono rilevanti per le indagini IOC relative a dominio/hostname/IP.

Detection: Raccogliere i log di PowerShell da Windows PowerShell ETW Provider
Questi log contengono i metadati dei comandi che gli aggressori usano su PowerShell. Le nuove connessioni di rete effettuate o tentate verranno loggate e includeranno l’IP (interno o esterno) come destinazione. Questi sono segni di esfiltrazione (caricamento e invio di dati a un endpoint dannoso).

Anche se il payload fosse costituito da comandi o dati offuscati in base64, rendendo così difficile l’analisi e la creazione di regole, poiché le regole dipendono da determinati modelli, la raccolta di tali log può comunque aiutare a trovare eventuali valori anomali. Esistono strumenti di analisi aggiuntivi come lo strumento ee-outlier tool by NVISO-BE per questi tipi di attività.

Detection: Ricerca del tunneling DNS tramite logging e monitoraggio o DNS Query e Responses
Il tunneling DNS (un metodo di Exfiltration Over Alternative Protocol) è dove “gli avversari possono rubare i dati esfiltrandoli su un protocollo diverso da quello del canale di comando e controllo esistente”. Gli aggressori possono utilizzare il campo del sottodominio DNS per esfiltrare i dati, oltre ad altri modi per abusare del protocollo DNS per gli attacchi.

Il tunneling DNS a un server di Command e Control utilizza il protocollo DNS come un modo per offuscare gli attacchi. Uno dei motivi di questa tecnica è che i difensori hanno un tempo minore per monitorare le cattive attività sugli endpoint più comuni come RDP, il tunneling DNS abusa del protocollo DNS per intrufolarsi in comandi e dati come l’esfiltrazione. La ricerca di attacchi di tunneling DNS implica il logging di query e risposte DNS.

Nota: se sei interessato a saperne di più su questi tipi di log e metadati, le prossime parti di questa serie si concentreranno maggiormente sul deployment dei log e sugli esempi di log.

Conclusione
In questa parte della serie, leggiamo ulteriormente il valore della sicurezza ottenuto dalla log collection mirata, che deve essere consapevole del fatto che non tutte le origini di log sono le stesse in termini di affidabilità e qualità degli eventi di log. Garantire che queste fonti di log facciano parte della tua esposizione aiuta a fornire agli IOC un percorso di indagine su Iris o indagini tramite l’API o l’integrazione di DomainTools.

Ogni tanto riceviamo richieste di (possibile) aiuto post-sfruttamento e di immergerci nei dati di dominio per trovare indizi post-sfruttamento. Sebbene la serie non approfondisca le parti operative della ricerca delle minacce, è importante che le distribuzioni vedano il valore dell’aumento dell’esposizione dei log, nonostante le sfide della gestione delle origini dei log (e dei loro tipi di log, metadati, campi mancanti e così via). Nella prossima serie, entreremo nelle specifiche di questi, coprendo le opportunità e le sfide rispettivamente nelle piattaforme Windows e Linux.

Per sapere come identificare e tenere traccia delle operazioni avversarie in DomainTools Iris, visita la nostra pagina del prodotto.

Vai al post originale

Azure AD DNS Filtering: Cos’è e quali sono i vantaggi?

da Domenico Panetta | Set 7, 2021 | How-To

Il cloud computing e il lavoro a distanza hanno portato a attacchi informatici via web, apparentemente senza fine. Ma in un recente report pubblicato da una azienda leader nel PAM, quasi tre quarti degli hacker black hat hanno affermato che la sicurezza tradizionale del firewall e dell’antivirus non poteva fermarli. Poiché queste misure di sicurezza tradizionali si adattano per contrastare gli attacchi informatici, le tattiche di hacking collaudate, come il phishing e il malware drive-by-download, si trasformano per eludere il rilevamento.

Un metodo alternativo per bloccare alla fonte gli attacchi informatici via Web, è il filtro DNS che può essere profondamente integrato con Microsoft Azure Active Directory (AD) per offrire il filtro DNS di Azure basato sull’accesso a livello di utente. Qui spieghiamo cos’è, come funziona e quali vantaggi offre a un’azienda oltre alle tradizionali misure di sicurezza.

Cos’è un DNS? E dove si adatta Microsoft Azure?

Un DNS (Domain Name System) è alla base di Internet, mappando un nome di dominio leggibile dall’uomo su un indirizzo IP leggibile dalla macchina (IP sta per Internet Protocol), ad es.

https://wtc1.webtitancloud.com:8443
viene risolto in
52.32.39.15

Quando un utente digita un indirizzo web in un browser, un “risolutore DNS” abbina questo dominio a un indirizzo IP utilizzando i server DNS. In altre parole, il sistema DNS risolve l’indirizzo e lo associa all’indirizzo IP. Questo indirizzo IP viene utilizzato per effettuare la connessione tra il dispositivo e l’indirizzo IP prima di caricare il contenuto.

Oggetti come un dispositivo mobile di un lavoratore remoto, hanno anche un indirizzo IP. I miliardi di oggetti, persone e siti Web dipendono tutti da un DNS funzionante per fornire contenuti e dati.

Un DNS è altamente distribuito e non si basa su un singolo server. I domini in Azure sono ospitati su una rete globale di server dei nomi DNS gestiti dall’infrastruttura cloud di Azure. L’intero sistema è configurato per ottimizzare la velocità e l’alta disponibilità per un determinato dominio. Gli amministratori di Azure usano DNS di Azure per i servizi tra cui hosting di siti Web, applicazioni, API, hosting di servizi cloud e gestione della zona DNS.

Cos’è il filtro DNS di Azure?

Il filtro DNS è un metodo utilizzato per impedire agli utenti di accedere a determinati siti Web o indirizzi IP. Questo è importante in quanto tattiche come il phishing e i siti Web infetti da malware sono metodi di attacco informatico di successo che utilizzano Internet. Il filtro DNS funziona insieme al sistema DNS. Quando un resolver DNS è configurato per bloccare un determinato indirizzo IP, aggiungendolo a una “block list”, a un utente viene impedito di navigare verso quell’indirizzo IP. In genere, questa blocklist contiene siti Web dannosi. Allo stesso modo, un filtro DNS può anche consentire la visita a determinati siti Web, inserendoli in una “white list” di siti sicuri da usare. Il filtro DNS può essere applicato anche in base al dispositivo, ad esempio applicando criteri di filtro agli utenti Chromebook del settore educativo. Il filtro DNS di Azure può essere applicato a servizi ospitati specifici di Azure per creare zone sicure a cui gli utenti possono accedere.

DNS Filtering basato su Azure Active Directory (AAD)

Azure AD è una directory che può essere usata per applicare il controllo degli accessi in base al ruolo. Il filtro DNS di Azure usa criteri che si estendono a un’intera organizzazione, applicando e monitorando i filtri usando questi criteri applicati all’appartenenza al gruppo AD. WebTitan, ad esempio, è profondamente integrato con Azure AD, utilizzando un’app Azure AD Enterprise per analizzare qualsiasi accesso di Azure per trovare nuovi utenti. Questi utenti vengono quindi associati all’IP di qualsiasi macchina virtuale utilizzata per l’accesso e vengono applicati criteri di sicurezza e di accesso come appropriato.

Vantaggi dell’utilizzo del filtro DNS di Azure

Una soluzione di filtraggio DNS basata sull’intelligenza artificiale, come WebTitan, utilizza tecniche avanzate come l’apprendimento automatico, per assicurare protezione anche dalle minacce zero-hour. Se integrati con Azure AD, i criteri di sicurezza necessari per gestire e controllare l’accesso dei dipendenti possono essere applicati automaticamente e gestiti da remoto. Una soluzione di filtraggio DNS, in particolare una che può adattarsi selettivamente alle minacce zero-hour, offre importanti vantaggi per proteggere le organizzazioni da attacchi informatici via web:

Blocca dinamicamente l’accesso al sito web inappropriato o dannoso
I siti Web infetti da malware vengono utilizzati come esca per attirare gli utenti e infettare tutti i dispositivi che si connettono all’indirizzo IP del dominio dannoso. Altri siti potrebbero contenere materiale inappropriato. Gli utenti sono incoraggiati ad aprire tali siti utilizzando tecniche di ingegneria sociale. Se un utente accede a un sito dannoso, il codice dannoso sfrutta le vulnerabilità nei browser senza patch o configurati male, infettando il dispositivo con malware.Può essere difficile per le soluzioni antivirus o antispam tradizionali prevenire l’impatto di questi siti poiché emergono nuove varianti progettate per eludere il rilevamento da parte delle misure di sicurezza tradizionali. Una delle tattiche più recenti consiste nell’usare le app di Azure come vettore per l’infezione da malware o il furto di credenziali. Gli hacker usano app di Azure dall’aspetto realistico ma dannose per incoraggiare gli utenti a navigare in un sito Web controllato da un utente malintenzionato per eseguire l’attacco completo. L’uso di un filtro DNS blocca attacchi come questo interrompendo il percorso verso il sito Web dannoso. Utilizzando un filtro DNS basato sull’appartenenza ad Azure AD, un’azienda può mappare in modo rapido e dinamico un utente o un ruolo di Active Directory per interrompere l’accesso a siti Web dannosi nuovi e consolidati.
Blocca i siti Web di phishing
Nel 2020 il 75% delle organizzazioni ha subito un attacco di phishing. Questi attacchi spesso iniziano con l’incoraggiamento dell’utente a visitare un sito Web di phishing. Una volta che l’utente entra in quel sito dannoso, le credenziali di accesso, i dati e/o l’accesso alle risorse aziendali sono a rischio. La tecnologia intelligente basata sull’intelligenza artificiale garantirà che anche le minacce zero-hour siano mitigate.
Blocca l’infezione da ransomware e il furto di dati
Il ransomware è il malware del momento. Il ransomware non riguarda più la crittografia dei dati e l’estorsione di denaro per una chiave di decrittazione. Ora, secondo IBM X-Force, il 59% degli incidenti ransomware include anche l’esfiltrazione dei dati, i dati rubati vengono quindi utilizzati per fare pressione sulle organizzazioni affinché paghino. Tuttavia, anche se viene pagato un riscatto, non vi è alcuna garanzia che i dati rubati non vengano venduti e utilizzati per frodi. Il ransomware, spesso, infetta un’azienda tramite e-mail di phishing e siti Web infetti. Il Verizon Data Breach Investigation Report (DBIR) afferma che nell’85% delle violazioni dei dati è coinvolto un essere umano, di solito navigando su un sito Web infetto o facendo clic su un collegamento in un’e-mail di phishing. Il filtro DNS di Azure impedisce ai membri di Azure AD di diventare parte dell’85% degli esseri umani che aiutano la propagazione delle infezioni ransomware.
Proteggi i dispositivi
Il lavoro a distanza e da casa, ha fatto sì che i dispositivi personali venissero utilizzati per le attività lavorative. Tuttavia, i dispositivi personali sono molto più difficili da proteggere poiché le policy sono più difficili da applicare e gestire in remoto. Usando un filtro DNS di Azure AD che usa agenti basati su dispositivi gestiti in remoto, anche i dispositivi personali possono essere protetti da infezioni da software dannoso.
Semplice da configurare e utilizzare
Infine, qualsiasi filtro DNS deve essere facile da configurare e configurabile in remoto per una forza lavoro basata su cloud/remota. Gli ambienti cloud cambiano continuamente, aggiungendo nuove app e nuovi endpoint, che richiedono policy appropriate per ambienti diversi. I filtri DNS devono essere facili da impostare, configurare e modificare. I filtri dei contenuti basati su API consentono la configurazione e il monitoraggio remoti. Il mapping di Azure AD all’accesso al sito Web offre un modo semplice per creare criteri di sicurezza in base a utente/per ruolo.Applicando il potente controllo del filtro DNS integrato in Azure AD all’accesso al Web, un’organizzazione può migliorare la propria postura di sicurezza e ridurre i rischi relativi al Web. Un filtro DNS offre a un’organizzazione un modo per migliorare la navigazione web sicura della sua forza lavoro, prevenendo il furto di dati e credenziali, ransomware e altri attacchi informatici, nonché l’uso inappropriato del web.

Contattaci per una trial della soluzione di filtraggio DNS di WebTitan e scopri come si integra direttamente con Azure AD.

Vai al post originale

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

da Domenico Panetta | Set 2, 2021 | How-To

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

CREST Cyber Security Monitoring and Logging Guide
UK NCSC Logging Made Easy
NIST SP 800-81-2 Secure Domain System (DNS) Deployment Guide
PCI su Effective Daily Log Monitoring

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.

Vai al post originale

WebTitan Cloud vs Cisco Umbrella

da Domenico Panetta | Set 1, 2021 | Notizie dal Mercato

WebTitan Cloud vs Cisco Umbrella

OpenDNS era un servizio di web filtering gratuito basato su DNS, anche se da allora è stato acquisito da Cisco ed è stato rinominato Cisco Umbrella. Cisco Umbrella è un filtro web popolare per le aziende, anche se molte aziende stanno abbandonando il prodotto e stanno passando a WebTitan Cloud e in questo post “WebTitan Cloud vs Cisco Umbrella“, verranno trattati alcuni dei motivi principali alla base di questo passaggio.

Sebbene esistano molte differenze tra WebTitan Cloud e Cisco Umbrella, entrambi i prodotti svolgono la stessa funzione. Consentono alle aziende di esercitare il controllo su siti Web, pagine Web e contenuti a cui possono accedere i propri utenti e ospiti.

TitanHQ ha aiutato centinaia di aziende a passare da Cisco Umbrella a WebTitan Cloud. Nella maggior parte dei casi, il motivo principale per cui le aziende cercano un’alternativa a Cisco Umbrella è risparmiare denaro. Il prezzo di Cisco Umbrella riflette la natura globale del prodotto, ma il costo di Cisco Umbrella è considerato troppo elevato da molte piccole e medie imprese che cercano solo protezione da malware e phishing e per controllare i siti Web a cui i dipendenti possono accedere.

Il costo di Cisco Umbrella è difficile da giustificare per molte PMI e fornitori di servizi gestiti (MSP). Il costo per utente è notevolmente superiore a molte altre soluzioni sul mercato. In effetti, potresti essere sorpreso di quanto denaro può essere risparmiato cambiando il tuo provider di filtri web.

WebTitan Cloud vs Cisco Umbrella: Differenze Chiave

Costo e prezzo

Uno dei motivi principali per cui le aziende passano da Cisco Umbrella a WebTitan è il costo. Cisco Umbrella è una potente soluzione di filtro web, ma in generale, WebTitan Cloud offre funzionalità simili ed è uno scambio diretto. Le aziende che effettuano il passaggio possono continuare a filtrare Internet per proteggersi dalle minacce basate sul Web ed esercitare il controllo dei contenuti risparmiando fino al 50%.

I prezzi di Cisco Umbrella non sono particolarmente trasparenti. Per cominciare, non è possibile scoprire facilmente quanto probabilmente costerà, sul sito Web non è presente alcun calcolatore dei costi né alcun listino prezzi. Chi cerca informazioni sui prezzi di Cisco Umbrella online, è probabile che trovi i prezzi di vari rivenditori, ma questi prezzi, molto spesso, non sono aggiornati.

I prezzi di Cisco Umbrella dipendono da diversi fattori, tra cui il livello di protezione che si desidera, il numero di utenti da proteggere e la durata del contratto. Bisogna anche tenere conto di eventuali componenti aggiuntivi di cui si potrebbe aver bisogno. Ad esempio, viene fornito il supporto di base, ma il supporto avanzato ha un costo aggiuntivo. Poiché sono disponibili molte opzioni diverse, è necessario contattare Cisco per un preventivo individuale per la propria azienda.

La licenza di Cisco Umbrella si basa su tre pacchetti. Il pacchetto più semplice è DNS Security Essentials, noto come Cisco Umbrella Professional. Il livello successivo del prodotto è DNS Security Advantage, precedentemente Cisco Umbrella Insights. La soluzione più completa della famiglia Cisco Umbrella è DNS Secure Internet Gateway, precedentemente Cisco Umbrella Platform.

Il prezzo di Cisco Umbrella è stato stabilito in base alla natura completa del prodotto, che non solo fornisce il filtro DNS, ma include una serie di altre funzionalità. Alcune aziende, in particolare le grandi imprese che hanno una forza lavoro enorme, sono spesso prese di mira dagli attori delle minacce e necessitano di una vasta suite di soluzioni di sicurezza informatica per bloccare gli attacchi e condurre indagini approfondite. Per queste organizzazioni, è probabile che le funzionalità incluse nel pacchetto ombrello Cisco più completo possano essere attraenti e per quelle aziende il prezzo può essere facilmente giustificato. Le piccole e medie imprese possono trovare le caratteristiche aggiuntive del secondo e terzo livello delle soluzioni eccedenti rispetto ai requisiti.

La licenza di Cisco Umbrella si basa sul numero di utenti che devono essere protetti, con il prezzo di Cisco Umbrella per utente che diminuisce leggermente quanto più utenti verranno protetti. La licenza Cisco Umbrella ha una durata minima del contratto di 1 anno, sebbene sia possibile acquistare contratti più lunghi.

TitanHQ offre un modello di prezzo semplice e trasparente con fatturazione mensile. Tutte le funzionalità sono incluse nel prezzo, piuttosto che il sistema multilivello di filtraggio DNS di Umbrella, che fornisce le funzionalità avanzate solo nei livelli di prodotto superiori.

Interfaccia utente e reportistica

Una delle principali lamentele su Cisco Umbrella è la natura complicata del prodotto. C’è una ordering guide di Cisco Umbrella, che fornisce un’idea della complessità del prodotto e spiega i diversi pacchetti e opzioni disponibili, per determinare la versione della soluzione e le funzionalità necessarie. La complessità si estende al funzionamento della soluzione. Molti utenti si lamentano dell’interfaccia utente eccessivamente complicata, che può rendere la configurazione, la manutenzione e la generazione di report, attività lunghe e difficili. Se al personale non piace usare un prodotto, potrebbe evitarlo, il che avrà un impatto sulla sicurezza.

WebTitan Cloud ha un’interfaccia utente altamente intuitiva con tutte le informazioni a portata di mano. Ciò semplifica la configurazione e la gestione senza la necessità di formazione dell’utente. Significa anche che i problemi possono essere rapidamente identificati e risolti, migliorando la sicurezza.

Flessibilità

Cisco ha una gamma di prodotti vasta e diversificata ed è un enorme provider IT. Sebbene i suoi prodotti siano stati sviluppati per soddisfare le esigenze delle aziende, le opzioni disponibili sono piuttosto rigide.

TitanHQ è molto più piccolo in confronto, ma come entità indipendente, ha la flessibilità di lavorare a più stretto contatto con i clienti e soddisfare meglio le esigenze delle piccole e medie imprese. Gli accordi commerciali possono essere presi per soddisfare entrambe le parti.

Supporto

L’assistenza di Cisco Umbrella, viene fornita solo ai clienti con piani platino, oro o argento. I clienti TitanHQ beneficiano di un’assistenza clienti leader del settore, con supporto completo fornito a tutti i clienti senza costi aggiuntivi. Ciò include il supporto durante la prova gratuita del prodotto.

Cloud Keys

Al fine di proteggere l’intera rete aziendale, WebTitan Cloud applica regole di sicurezza all’intera organizzazione, oltre all’integrazione AD/LDAP per consentire l’applicazione di regole per gruppi e individui. A volte, le persone possono richiedere l’accesso a contenuti che violano le regole a livello aziendale. WebTitan Cloud consente di generare chiavi cloud che consentendo di bypassare temporaneamente i controlli di filtraggio senza la necessità di modificare i criteri e che possono essere configurati per scadere dopo un determinato periodo di tempo o un numero di utilizzi, continuando tuttavia e registrare e tenere traccia dei siti web visitati.

Capacità On premise

Alcune aziende non avranno remore a utilizzare un filtro web ospitato sui server del fornitore di servizi, sebbene questo sia tutt’altro che ideale per alcune aziende come System Integrato, Managed Service Provider (MSP) e Managed Security Service Provider (MSSP). Le aziende che non desiderano indirizzare gli utenti a un servizio cloud esterno possono ospitare WebTitan Cloud in un cloud privato o ospitare la soluzione On Premise.

Con Cisco Umbrella, l’hosting locale non è un’opzione.

Possibilità di personalizzare la soluzione

Un altro motivo per System Integrato, MSP e MSSP per scaegliere WebTitan, è la mancanza di possibilità di rebranding di Cisco Umbrella.

WebTitan Cloud d’altra parte è completamente rebrandable e personalizzabile. Ciò include un’interfaccia utente personalizzabile e una pagina di blocco pronta per il rebranding. Ciò consente ai fornitori di servizi di offrire la soluzione ai propri clienti rafforzando al contempo il proprio brand.

WebTitan Cloud vs Cisco Umbrella

Ulteriori informazioni su WebTitan Cloud
Il confronto fatto tra WebTitan Cloud e Cisco Umbrella include solo alcuni dei motivi per cui le aziende stanno passando a WebTitan Cloud. Per ulteriori approfondimenti consulta la Cisco Umbrella Alternatives 2020 oppure contattaci oggi per programmare una dimostrazione del prodotto e scoprire come funziona WebTitan.

ReaQta annuncia Cyber Assistant, primo sistema di gestione degli avvisi basato su IA

da Domenico Panetta | Set 1, 2021 | Notizie dal Mercato

ReaQta lancia Cyber Assistant per gestire autonomamente gli avvisi e ridurre drasticamente il carico di lavoro dell’analista di oltre l’80%
Cyber Assistant utilizza tecnologie innovative nell’intelligenza artificiale, che include il primo sistema di apprendimento one-shot del settore
Questa nuova versione potenzia ulteriormente il potente stack di sicurezza degli endpoint di ReaQta offrendo un nuovo modulo di amministrazione multi client e una panoramica dei prodotti installati in finestra.

Amsterdam, Paesi Bassi, 1 settembre 2021 – ReaQta ha annunciato oggi il rilascio di una nuova versione della sua Autonomous Detection & Response Platform, ReaQta-Hive. Quest’ultima versione, ReaQta-Hive 3.6, ottimizza il design intuitivo della piattaforma sia per gli analisti che per i Managed Security Service Providers, sfruttando innovazioni AI rivoluzionarie in un nuovissimo sistema di gestione degli avvisi autonomo: Cyber Assistant.

Utilizzando il deep graph learning, ReaQta apre la strada alle sue ultime automazioni per aumentare il ROI, aumentare l’efficienza del team e migliorare la precisione degli avvisi.

Le nuove funzionalità includono:

ReaQta Cyber Assistant

Un componente nuovo e attivo di ReaQta-Hive, creato per gestire autonomamente gli avvisi e alleviare l’alert fatigue riducendo i falsi positivi di oltre l’80%.

La maggiore interconnettività di endpoint, dati e l’aumento di attività dannose da parte degli attori delle minacce negli ultimi anni hanno creato un aumento sostanziale delle attività che devono essere gestite dagli analisti.

Gli analisti devono passare attraverso un flusso crescente di avvisi provenienti da varie fonti. Ciò aumenta i tempi di risposta, genera alert fatigue e, nel peggiore dei casi, provoca l’abbandono dei dipendenti.

Cyber Assistant è il primo sistema di apprendimento one-shot del settore che mostra la leadership tecnologica di ReaQta nella protezione degli endpoint e mantiene la sua promessa di semplificare la sicurezza informatica. Adottando l’apprendimento one-shot, il Cyber Assistant di ReaQta è in grado di apprendere la decisione di un analista immediatamente dopo aver visto un determinato avviso solo una volta.

Cyber Assistant avvantaggia i clienti con:

Apprendimento e applicazione automatica del processo decisionale quotidiano degli analisti all’interno del proprio ambiente o in più ambienti per i partner MSSP.
Libera tempo prezioso per consentire agli analisti di concentrarsi su analisi di livello superiore, caccia alle minacce e altre attività.
Essendo privo di problemi, allevia la fuga di cervelli poiché gli apprendimenti sono collegati alla funzione lavorativa, non all’analista.
Mantenere bassi i costi di formazione/riqualificazione poiché le conoscenze vengono conservate con Cyber Assistant.
Ridurre i costi di servizio poiché Cyber Assistant non richiede regolari “tune-ups” o “refreshments” esterni per ottimizzare le sue operazioni.

Cyber Assistant non è venduto come aggiornamento o prodotto separato, ma è ora disponibile per tutti i clienti ReaQta-Hive.

“Siamo orgogliosi che ReaQta sia stata nominata Gartner Cool Vendor nel mercato della protezione degli endpoint per il nostro utilizzo di AI & ML e dell’agente NanoOS™. Oggi siamo lieti di annunciare la nostra terza innovazione nel settore con Cyber Assistant che riduce drasticamente il carico di lavoro degli analisti di oltre l’80%, rimettendo saldamente in controllo i difensori anche in una realtà di dati e attacchi in continua crescita”. – Alberto Pelliccione, CEO di ReaQta.

Multi-Client Admin

Il nuovo e potente livello di gestione di ReaQta consente agli MSSP e ai clienti di gestire ambienti client separati e multilivello come fosse uno, migliorando l’efficienza con la caccia alle minacce tra clienti e la propagazione delle policy.

Progettati per una facilità d’uso ancora maggiore nelle implementazioni cloud, i partner large-scale possono ora ospitare più MSSP all’interno della stessa infrastruttura, offrendo loro la possibilità di gestire più clienti contemporaneamente senza l’onere della manutenzione dell’infrastruttura.

Windows Installed Products

Per aiutare gli analisti a prendere decisioni migliori e più rapide durante la valutazione delle minacce, il software installato sui computer Windows è ora disponibile a livello di informazioni sugli endpoint per offrire ai clienti una comprensione completa di quale software è installato su endpoint specifici.

Guarda ReaQta-Hive in azione o contattaci per una demo.

Informazioni su ReaQta

ReaQta è la top-tiered AI Autonomous Detection & Response platform, creata da un gruppo elitario di esperti di sicurezza informatica e ricercatori di AI/ML con una vasta esperienza nelle operazioni di intelligence del governo. Costruito con funzionalità avanzate di ricerca automatica delle minacce, ReaQta consente alle organizzazioni di eliminare le minacce più avanzate in tempo reale.

In qualità di esperti in intelligenza artificiale e analisi comportamentale, i motori dual-AI proprietari di ReaQta forniscono alle organizzazioni di tutti i settori una sicurezza degli endpoint autonoma, in tempo reale e completamente personalizzabile, senza la complessità. Come risultato di livelli di automazione senza precedenti abbinati a un design intuitivo, i clienti e i partner di ReaQta beneficiano di miglioramenti delle prestazioni e sono ora in grado di gestire e proteggere più endpoint senza la necessità di personale altamente qualificato. Per ulteriori informazioni, visita ReaQta.com

ReaQta è stato recentemente nominato Cool Vendor da Gartner in Network and Endpoint Security. Con la chiusura del round di finanziamento della serie A, è destinata a espandere rapidamente le operazioni commerciali, in particolare in Europa e in Asia.

Vai al post originale

Rapid7 acquisisce IntSights, leader nell’intelligence sulle minacce

da Domenico Panetta | Ago 2, 2021 | Notizie dal Mercato

IntSights, soluzione di cyber Intelligence che offre il rilevamento delle minacce esterne cloud-native best-in-class per estendere ulteriormente la piattaforma di operazioni di sicurezza leader del settore di Rapid7, fornendo ai clienti rilevamento, automazione e risoluzione delle minacce interne ed esterne end-to-end. Le nuove funzionalità combinate miglioreranno l’offerta di rilevamento e risposta estesa (XDR) best-in-class di Rapid7, nativa per il cloud, consentendo un maggiore rapporto segnale-rumore, rilevamento tempestivo delle minacce e risposta accelerata.

Boston, MA — 19 luglio 2021
Rapid7, Inc. (NASDAQ: RPD), fornitore leader di analisi e automazione della sicurezza, ha annunciato oggi di aver acquisito IntSights Cyber Intelligence Ltd., leader nell’intelligence contestualizzata sulle minacce esterne e nella risoluzione proattiva delle minacce. Secondo i termini dell’accordo, Rapid7 pagherà circa 335 milioni di dollari in contanti e azioni per acquisire IntSights, soggetti a modifiche.

Con la trasformazione digitale, la superficie di attacco è aumentata in modo esponenziale, rendendo imperativo per i team di sicurezza il rilevamento tempestivo e contestualizzato delle minacce nei loro ambienti interni ed esterni. Tuttavia, la maggior parte dei team di sicurezza ha risorse insufficienti e sovraccarico, inondata da una marea di dati dal proprio ambiente e lotta per identificare ciò che richiede un’azione immediata.

Con l’acquisizione di IntSights, Rapid7 unirà la sua intelligence sulle minacce infusa dalla comunità e la profonda comprensione degli ambienti dei clienti con le capacità di intelligence sulle minacce esterne di IntSights. Questa combinazione ha lo scopo di fornire ai clienti una visione unificata delle minacce, monitoraggio della superficie di attacco, approfondimenti rilevanti e mitigazione proattiva delle minacce per le organizzazioni di qualsiasi dimensione o livello di maturità della sicurezza. Questa acquisizione migliora anche l’offerta di rilevamento e risposta estesa (XDR) cloud-native leader di Rapid7, InsightIDR, consentendo avvisi di alta qualità e alta fedeltà per garantire operazioni di sicurezza efficienti, rilevamento tempestivo delle minacce e tempi di risposta accelerati.

IntSights consente alle organizzazioni di ottenere tutti i vantaggi di un programma di intelligence sulle minacce, indipendentemente dall’ambito o dalla complessità, riducendo inoltre in modo significativo il carico di lavoro sui team di sicurezza. A differenza di molti altri strumenti di intelligence sulle minacce presenti oggi sul mercato, IntSights è in grado di promuovere la produttività e i risultati di cui i team operativi di sicurezza di oggi hanno bisogno fornendo una copertura continua per le minacce esterne, dall’identificazione alla mitigazione fino alla risoluzione.

Insight Platform di Rapid7 è una delle piattaforme per le operazioni di sicurezza più complete oggi sul mercato, con un’ampia gamma di funzionalità all’avanguardia per rilevamento e risposta, gestione delle vulnerabilità, sicurezza del cloud, sicurezza delle applicazioni, orchestrazione e automazione della sicurezza. Oltre a potenziare la propria offerta XDR e a vendere un’offerta standalone di intelligence sulle minacce, l’azienda intende portare le funzionalità di intelligence sulle minacce esterne di IntSights nella sua piattaforma per sbloccare più rapidamente l’identificazione e la risoluzione delle minacce nell’intero portafoglio di soluzioni dell’azienda.

Foros ha agito in qualità di advisor finanziario di Rapid7.

Citazioni

“Oggi la sicurezza informatica è una battaglia asimmetrica e le probabilità favoriscono costantemente gli aggressori”, ha affermato Corey Thomas, presidente e CEO di Rapid7. “Sia IntSights che Rapid7 hanno la convinzione condivisa che le organizzazioni avranno successo solo quando avranno una visione unificata delle minacce interne ed esterne, completa di intelligence contestualizzata e mitigazione automatizzata delle minacce che consentirà ai team di sicurezza di concentrarsi sulle minacce più critiche. Non vediamo l’ora di lavorare con IntSights per rendere questa visione una realtà per i nostri clienti”.

“Oggi non mancano le informazioni di intelligence sulle minacce disponibili, ma molte di esse mancano di contesto, creando troppo rumore di allerta e lavoro aggiuntivo per i team di sicurezza già sovraccarichi”, ha affermato Richard Perkett, vicepresidente senior del rilevamento e della risposta presso Rapid7. “Integrando Le capacità di intelligence sulle minacce esterne di IntSights nella soluzione XDR di Rapid7, InsightIDR, prevediamo di fornire ai team di sicurezza visibilità e rilevamento ampliati delle minacce interne ed esterne nei loro ambienti tradizionali e moderni, consentendo loro di orientarsi rapidamente nelle indagini, nella ricerca delle minacce e nell’automazione del contenimento. all’interno di un’esperienza unificata.”

“Abbiamo fondato IntSights per rendere l’intelligence sulle minacce immediatamente accessibile e utilizzabile per le organizzazioni di qualsiasi tipo o dimensione”, ha affermato Guy Nizan, co-fondatore e CEO di IntSights. “Siamo entusiasti di unirci a Rapid7 per continuare questa missione e portare le nostre capacità di intelligence sulle minacce a un numero ancora maggiore di clienti”.

“Con la superficie di attacco tentacolare di oggi e il livello di sofisticatezza degli attori delle minacce, non posso sopravvalutare l’importanza di un solido programma di intelligence sulle minacce”, ha commentato Jon Oltsik, analista principale senior e membro dell’Enterprise Strategy Group (ESG). “Le minacce possono provenire da qualsiasi luogo, motivo per cui è imperativo avere visibilità nel panorama delle minacce interne ed esterne. Con l’acquisizione di IntSights, Rapid7 è in una buona posizione per colmare il divario di intelligence sulle minacce, offrendo ai clienti la possibilità di identificare le minacce reali in anticipo, accelerare la risposta e automatizzare la risoluzione”.

Risultati preliminari del secondo trimestre 2021

Rapid7 ha anche fornito una stima preliminare dei risultati Annualized Recurring Revenue (ARR) per il secondo trimestre conclusosi il 30 giugno 2021. Sulla base delle informazioni attualmente disponibili, Rapid7 prevede che l’ARR chiuderà il secondo trimestre 2021 a circa $ 489 milioni, o una crescita del 29% rispetto all’anno precedente. -anno. Inoltre, Rapid7 prevede che i ricavi e le entrate non GAAP derivanti dalle operazioni per il secondo trimestre 2021 supereranno la fascia alta delle precedenti indicazioni di Rapid7 fornite il 6 maggio 2021. La società discuterà i risultati finanziari completi durante la teleconferenza sugli utili del secondo trimestre il 4 agosto 2021.

Leggi qui per saperne di più su questa acquisizione.

Vai al post originale

Accesso semplificato a AWS Managed Services con OneLogin

da Domenico Panetta | Lug 13, 2021 | How-To

OneLogin, partner AWS Security Competency, fornisce una piattaforma di identità per esperienze di accesso agli AWS Managed Services sicure, scalabili e intelligenti che collegano le persone alla tecnologia.

Il motore di autenticazione e provisioning degli utenti basato sui ruoli di OneLogin, consente di implementare controlli di accesso con privilegi minimi ed eliminare i processi di gestione manuale degli utenti per tutti gli utenti e gli account di Amazon Web Services (AWS).

In questo post ricapitoliamo tutte le integrazioni disponibili tra OneLogin e AWS. Attraverso queste integrazioni, OneLogin consente di autenticarsi senza problemi nei servizi gestiti AWS in vari domini, inclusi analytics, compute, serverless, secuity, management & governance e altro ancora.

Workforce Identity – Single Sign-On utilizzando OneLogin e AWS SSO
AWS Single Sign-On (AWS SSO) consente di gestire in modo efficiente le identità degli utenti su larga scala, stabilendo un’unica identità e una strategia di accesso tra le tue applicazioni, applicazioni SaaS (Software-as-a-Service) di terze parti e ambienti AWS.

La federazione dell’accesso tra AWS SSO e OneLogin consente di accedere ad AWS SSO con un solo clic. Una volta configurata la federazione di accesso da OneLogin, gli utenti finali possono accedere con OneLogin per ottenere l’accesso a tutti gli account AWS assegnati.

AWS SSO e OneLogin utilizzano System for Cross-domain Identity Management (SCIM), che consente il provisioning automatico degli utenti. Questo post del blog illustra come connettere OneLogin ad AWS SSO.

OneLogin supporta anche i tag di sessione con AWS SSO. Utilizzando i tag di sessione è possibile trasferire gli attributi dell’utente in AWS.

Analytics – Accesso federato ad Amazon Redshift
Amazon Redshift è un servizio di data warehouse in cloud, completamente gestito, che consente di ottenere facilmente nuove informazioni da tutti i dati contenuti.

La configurazione della federazione degli utenti Amazon Redshift da OneLogin, consente di gestire l’accesso alle risorse Amazon Redshift in maniera centralizzata, ciò elimina la necessità di utenti e password in database separati e migliora la sicurezza aziendale.

Amazon Redshift supporta SAML 2.0 e può essere facilmente configurato per l’integrazione con OneLogin. Questo post del blog illustra i passaggi necessari per configurare la federazione degli utenti Amazon Redshift da OneLogin. Spiega inoltre come trasferire l’appartenenza al gruppo da OneLogin ad AWS, che consente di gestire l’accesso degli utenti alle risorse Amazon Redshift dall’interno del provider di identità (IdP).

Monitoring – Accesso federato ad Amazon Managed Service per Grafana
Con Amazon Managed Service for Grafana (AMG), è possibile visualizzare e analizzare i dati operativi su larga scala senza dover eseguire il provisioning, configurare e aggiornare i server.

AMG è un servizio completamente gestito basato su Grafana, un popolare strumento open source che consente di interrogare, visualizzare, inviare avvisi e comprendere le metriche, indipendentemente da dove sono archiviate.

L’integrazione di OneLogin per il Single Sign-On in AMG utilizzando AWS SSO consente agli utenti senza accesso all’AWS Management Console di accedere a un ambiente AMG. Fornisce agli utenti un URL di accesso univoco che possono utilizzare per l’accesso diretto alle dashboard AMG, dove possono monitorare ed eseguire query sui dati da varie fonti, tra cui Amazon CloudWatch, Amazon Elasticsearch Service e Amazon Timestream.

Dopo una configurazione una tantum per stabilire l’attendibilità di SAML 2.0, è possibile continuare a gestire utenti e gruppi utilizzando l’IdP esistente, che può essere facilmente sincronizzato con AWS SSO utilizzando SCIM. Questo post sul blog mostra come implementare questa integrazione.

Federated Access ad Amazon Elasticsearch Service
Amazon Elasticsearch Service è un servizio completamente gestito che consente di distribuire ed eseguire Elasticsearch su larga scala.

Amazon Elasticsearch Service offre supporto nativo per l’autenticazione SAML, così può esssere integrato direttamente con IdP di terze parti come OneLogin per SSO in Kibana. Ciò consente di sfruttare le credenziali utente e i privilegi esistenti per l’accesso a Kibana e gestirli direttamente dal proprio IdP.

Questo post del blog contiene maggiori dettagli su questa funzione e la guida per gli sviluppatori contiene le istruzioni di configurazione.

Management and Governance – Federazione delle identità con AWS Control Tower e OneLogin
AWS Control Tower consente alle organizzazioni con più account AWS di configurare e gestire più facilmente il proprio ambiente AWS multi-account utilizzando le best practice AWS.

I connettori OneLogin consentono di gestire centralmente l’identità e la federazione degli accessi utilizzando vari archivi utente, come Active Directory, LDAP e Google, mentre si crea e si ridimensiona il proprio ambiente multi-account su AWS con Control Tower.

è possibile integrare OneLogin e Control Tower con AWS SSO o SAML. Questa guida all’implementazione illustra come configurare l’integrazione con AWS SSO utilizzando un modello AWS CloudFormation di esempio.

Network– Accesso federato tra AWS Client VPN e OneLogin
AWS Client VPN consente agli utenti remoti di connettersi in modo sicuro alle risorse su AWS e nella rete locale. Con il lancio di Federated Authentication via SAML 2.0, AWS Client VPN può ora essere configurato come provider di servizi nell’IdP esistente.

L’autenticazione federata basata su SAML diventa una terza opzione di autenticazione per Client VPN, oltre ad Active Directory e all’autenticazione reciproca basata su certificati.

OneLogin si integra con AWS Client VPN, consentendo agli utenti remoti che si connettono a Client VPN di autenticarsi con le stesse credenziali che utilizzano per qualsiasi altro servizio già integrato con OneLogin. Questa guida all’implementazione fornisce istruzioni per configurare la connessione tra il proprio IdP basato su SAML e Client VPN.

App Integration – Invio di eventi OneLogin ad Amazon EventBridge
Amazon EventBridge è un bus di eventi serverless che consente di creare applicazioni basate su eventi utilizzando i dati di tutte le origini, inclusi i dati di molte applicazioni SaaS.

L’integrazione di OneLogin per Amazon EventBridge consente alle organizzazioni di trasmettere i dati degli eventi da OneLogin a un bus di eventi e creare flussi di lavoro di identità personalizzati che combinano eventi e azioni OneLogin e AWS.

E’ possibile aggiungere OneLogin come event source del partner utilizzando la console AWS e completare la configurazione seguendo le istruzioni fornite nel sito Web del partner.

EventBridge consente di creare facilmente regole che si attivano su eventi ricevuti da OneLogin. Per le regole che si creano, è possibile definire le destinazioni, che sono servizi che rispondono agli eventi.

EventBridge supporta molti tipi di target. Questa documentazione contiene le istruzioni per configurare EventBridge per ricevere eventi da OneLogin.

Serverless – Autorizzatori AWS Lambda con OneLogin per controllare l’accesso di Amazon API Gateway
Amazon API Gateway è un servizio completamente gestito che semplifica la creazione, la pubblicazione, la manutenzione, il monitoraggio e la protezione delle API su qualsiasi scala. Supporta vari meccanismi per il controllo dell’accesso all’API, inclusi gli autori di autorizzazione AWS Lambda, che sono funzioni Lambda che utilizzano l’autenticazione del token portante per controllare chi può invocare i metodi API REST.

Se la propria organizzazione utilizza già OneLogin come IdP, è possibile creare autorizzazioni Lambda utilizzando le credenziali OneLogin senza dover configurare servizi aggiuntivi. Questo post per sviluppatori OneLogin illustra come creare e utilizzare un’autorizzazione OneLogin Lambda per controllare l’accesso alle API.

Customer Engagement – Abilitazione della federazione con AWS SSO e Amazon Connect
Amazon Connect è un contact center cloud omnicanale che ti aiuta a migliorare le esperienze dei clienti. Progettato da zero per essere omnicanale, Amazon Connect offre un’esperienza senza interruzioni tramite voce e chat per clienti e agenti.

L’integrazione di OneLogin con Amazon Connect consente di abilitare il single sign-on basato su SAML in Amazon Connect con RelayState.

RelayState è un parametro nell’asserzione SAML utilizzato per reindirizzare gli utenti autenticati a una determinata destinazione. Questa pagina OneLogin contiene maggiori dettagli su questa integrazione e sui suoi vantaggi.

Machine Learning – Onboarding di Amazon SageMaker Studio con AWS SSO e OneLogin
Amazon SageMaker Studio è un servizio completamente gestito che fornisce un ambiente di sviluppo integrato (IDE) basato sul Web che contiene tutti gli strumenti necessari per creare, addestrare e distribuire soluzioni di machine learning. Supporta il single sign-on con AWS SSO, che puoi integrare con OneLogin.

Quando si federa l’accesso tra OneLogin e AWS SSO come illustrato in questo post del blog, è possibile estendere l’accesso federato in Amazon SageMaker Studio seguendo queste istruzioni.

Ciò consente di gestire l’autenticazione dell’utente finale di Amazon SageMaker Studio da un’unica posizione centrale e gli utenti finali possono utilizzare le proprie credenziali OneLogin esistenti per l’accesso a Amazon SageMaker Studio.

Customer Identity – Configurazione di OneLogin come IdP SAML con un pool di utenti Amazon Cognito
Amazon Cognito fornisce soluzioni per controllare l’accesso alle risorse AWS dall’app. Consente di aggiungere la registrazione utente, l’accesso e il controllo degli accessi alle app Web e mobili in modo rapido e semplice.

Questo articolo spiega come integrare OneLogin come IdP SAML 2.0 con un pool di utenti Amazon Cognito.

Container – Introduzione all’autenticazione IdP OIDC per Amazon EKS
Amazon Elastic Kubernetes Service (Amazon EKS) offre la flessibilità di avviare, eseguire e ridimensionare le applicazioni Kubernetes nel cloud AWS o in locale.

Questo post del blog dimostra come i clienti possono integrare un provider di identità OIDC come OneLogin con un cluster EKS nuovo o esistente che esegue Kubernetes versione 1.16 o successiva.

Con questa funzionalità, è possibile gestire l’accesso degli utenti al tuo cluster sfruttando il ciclo di vita della gestione delle identità esistente tramite il proprio provider di identità OIDC come OneLogin.

Sommario
I clienti possono connettere la propria OneLogin Identity Management Platform con vari servizi gestiti AWS per gestire l’accesso ad AWS a livello centrale e anche consentire agli utenti finali di accedere utilizzando OneLogin per accedere a tutte le applicazioni AWS loro assegnate su AWS.

Queste integrazioni aiutano i clienti a semplificare la gestione degli accessi a più servizi AWS mantenendo le familiari esperienze OneLogin per gli amministratori che gestiscono le identità e per gli utenti finali quando accedono.

OneLogin – AWS Partner Spotlight
OneLogin è un AWS Security Competency Partner e una piattaforma di identità per esperienze sicure, scalabili e intelligenti che collegano le persone alla tecnologia.

Contattaci per saperne di più.

Vai al post originale

SpamTitan & Office365 Advanced Threat Protection

da Domenico Panetta | Lug 12, 2021 | Notizie dal Mercato

L’Advanced Threat Protection (ATP) è un tipo di soluzione di sicurezza che protegge le organizzazioni da malware e attacchi informatici complessi, che prendono di mira i dati sensibili. L’ATP difende dall’evoluzione delle tecniche e delle strategie di attacco informatico. Poiché le nuove tecniche di attacco informatico emergono costantemente, le organizzazioni non hanno la capacità di monitorare costantemente le ultime minacce emergenti, pertanto è necessaria l’ATP per bloccare attacchi informatici sofisticati noti e sconosciuti di spam.

Come funziona la protezione avanzata dalle minacce?
La difesa ATP di SpamTitan utilizza l’apprendimento automatico bayesiano integrato e l’euristica per difendersi dalle minacce avanzate.

Bayesian Analysis (Analisi Bayesiana): le organizzazioni possono bloccare un’e-mail in base al suo contenuto o ai file allegati, ad esempio i messaggi che contengono frasi specifiche nell’oggetto o nel corpo. L’analisi bayesiana apprende da ogni messaggio che scansiona: più messaggi scansiona, maggiore è la sua efficacia.
Auto Learning (Auto Apprendimento): utilizzo dell’intelligenza artificiale per prevenire le minacce informatiche e il rilevamento di schemi di pensiero in tempo reale.
Heuristics (Euristica): rilevamento dei virus esaminando il codice per le proprietà sospette.

Quali sono i tipi comuni di attacchi di minacce avanzate?

Ecco alcune Advanced Threat comuni che derivano dalla mancanza di una Advanced Threat Defense, che prendono di mira gli utenti di Office365:

Phishing Emails: questa è l’Advanced Threat più comune per gli utenti di Microsoft Exchange/Office365 che permette di accedere a una rete interna.
Malware: Installazione di malware in una rete interna, una volta che l’hacker ha avuto accesso alla rete interna potrà monitorare l’attività e rubare dati.
Stealing Credentials: gli aggressori possono monitorare il sistema e rubare credenziali sensibili per ottenere ulteriore accesso alla rete interna.
Gaining Network Access: mentre un utente malintenzionato ha accesso a una rete, l’aggressore può creare un percorso di ingresso per ottenere nuovamente l’accesso alla rete compromessa (backdoor).

Che cos’è l’Advanced Threat Protection di Office365?

Office365 è diventato un obiettivo primario per ransomware e attacchi di phishing. Uno studio di Deloitte afferma che “il 91% di tutti gli attacchi inizia con un’e-mail di phishing a una vittima ignara“.

SpamTitan si integra perfettamente con Microsoft Exchange/Office365 per fornire protezione avanzata dalle minacce alle organizzazioni da attacchi informatici sofisticati.

Nel 2016, uno studio ha rilevato che il 71,4% degli utenti aziendali di Office365 ha almeno un account compromesso ogni mese. Sebbene Office365 sia un brillante servizio di posta elettronica, manca in alcune aree come il filtro antispam, quindi è necessaria una soluzione di difesa avanzata dalle minacce come SpamTitan per difendersi dallo spam, dai criminali informatici e dalle minacce avanzate in continua evoluzione.

Come implementare un Advanced Threat Defense?

La soluzione Email Protection di SpamTitan contiene funzionalità pluripremiate per la protezione dalle minacce avanzate in Microsoft Exchange\Office365.

Funzionalità principali di SpamTitan e Advanced Threat Protection di Office365

Email Scanning: protezione mirata dalle minacce, scansione di ogni e-mail, allegato e URL a ogni clic per fornire una protezione avanzata dalle minacce da frodi di impersonation, ransomware, whaling, phishing e attacchi di spear-phishing.
Data Leak Prevention: potenti regole di Data Leak Prevention che prevengono la perdita di dati interni.
Sandboxing: il potente strumento di sandboxing di nuova generazione ispeziona tutti gli allegati alla ricerca di collegamenti dannosi o allegati di posta elettronica infetti. Se viene identificata un’attività dannosa, l’e-mail verrà messa in quarantena.
Zero-Day Threat Protection: utilizzo della tecnologia predittiva per anticipare nuovi attacchi.
Hosted Spam Filtering: le soluzioni di filtro antispam hosted rilevano lo spam e impediscono l’ingresso di e-mail dannose nella rete di un’organizzazione.
Double Antivirus Protection: SpamTitan integra BitDefender e ClamAV per proteggere i server da sofisticate informazioni sulle minacce, attacchi di phishing e minacce malware per una protezione avanzata dalle minacce.

SpamTitan integra tutte le funzionalità di Office365 che, una volta implementate permettono di avvalersi dell’Advanced Threat Technology di SpamTitan che include:

Un livello di protezione maggiore.
Un elevato catch rate dello spam.
Un maggiore livello di personalizzazione/granularità.
Migliori controlli della posta in uscita.
Business Continuity.

Contattaci per richiedere una demo di approfondimento o ottenere una licenza trial completa di SpamTitan (On Premises o Cloud).

Vai al post originale

I Remote Worker mettono a rischio la sicurezza informatica

da Domenico Panetta | Lug 9, 2021 | Notizie dal Mercato

I Remote Worker non sempre valutano il rischio delle loro attività per la sicurezza informatica.

Durante il passaggio al Remote Working, molte aziende non sono riuscite a comunicare (o non hanno potuto) l’importanza di attenersi alle politiche di sicurezza informatica per prevenire la sovrapposizione del’utilizzo dei dispositivi per attività di lavoro e attività personali, questo è quanto è emerso dai dati raccolti da Yubico.

La società ha intervistato 3000 lavoratori remoti in tutta Europa e ha scoperto che il 42% di essi, utilizza i dispositivi di lavoro per attività personali, di cui un terzo di questo gruppo, li utilizza per operazioni bancarie e acquisti, mentre il 7% visita siti web di streaming illegale. Su questo incide anche l’anzianità del personale, indicando i lavoratori più avanti con gli anni, come i peggiori trasgressori, inoltre il 43% degli imprenditori e il 39% dei dirigenti ammette di aver utilizzato i dispositivi di lavoro per attività personali, tra cui anche attività online illegali.

Sebbene l’utilizzo di un computer di lavoro (sia da casa che in ufficio) per un po’ di acquisti online non rappresenti di per sé una minaccia per la sicurezza informatica, la sovrapposizione tra attività personali e professionali, con i dipendenti che accedono al Web e ad altri servizi per motivi personali, aumenta il rischio di infezione da malware o ransomware, inclusa anche la compromissione accidentale dei dati aziendali. Non che questo non accadesse e non accade anche lavorando dall’ufficio (o in presenza), ma le reti aziendali dispongono spesso di molteplici layer di sicurezza che molte aziende legacy e impreparate a questa transizione, non hanno potuto o non sono riuscite ad estendere anche ai propri remote worker.

Remote Working & Sicurezza
Un’altra area molto vulnerabilità per molte aziende che utilizzano il modello Remote Working, è l’igiene delle password, spesso causata dall’impossibilità sempre per impreparazione o mancanza di soluzioni scalabili, di aggiornare le proprie password, come ad esempio quella di Dominio (On Prem) per accedere al proprio PC connesso tramite VPN. Secondo Yubico, il 54% dei dipendenti utilizza la stessa password su più account e servizi personali e di lavoro, senza dimenticare che il 22% del personale scrive ancora le proprie password su carta, incluso il 32% dei dirigenti.

Da questo rapporto, non rimangono esclusi neanche i dipartimenti IT, infatti Yubico ha scoperto che più di un terzo (37%) dei dipendenti remoti non ha ancora ricevuto alcun tipo di formazione o linee guida in ambito sicurezza informatica, mancanza che aiuta a capire come mai sia presente queta grossa lacune da parte dei dipendenti.

Per completare il panorama, sempre secondo i dati raccolti da Yubico, solo il 22% degli intervistati ha affermato che la propria azienda ha adottato soluzioni di 2FA o MFA proteggersi dall’Account Take Over (ATO), soluzioni che possono essere facilmente integrate in ambienti Legacy, e ancora di più di ambienti Cloud.

Contattaci per sapere come adottare rapidamente una di Strong Authentication (2FA, MFA o Passwordless) per ridurre il rischio informatico e prevenire l’Account Take Over.

Il NIST dice no, alle credenziali compromesse

da Domenico Panetta | Lug 9, 2021 | Notizie dal Mercato

Governi e aziende, stanno riconoscendo quanto siano vulnerabili i loro cittadini e dipendenti agli attacchi informatici e stanno iniziando a essere coinvolti, negli Stati Uniti, infatti, il National Institute of Standards and Technology (NIST) ha pubblicato la Digital Identity Guidelines che include una pubblicazione sull’Authentication and Lifecycle Management che è stata per la prima volta pubblicato nel giugno del 2017 ed è stato aggiornato di recente a marzo del 2020.

Non è che non sia mai stato detto prima, le password sono vulnerabili agli attacchi, le password possono essere facili da indovinare, le password possono essere violate utilizzando generatori di password casuali e, una volta violata una password in un sistema, può essere spesso utilizzata per violare un altro sistema perché gli utenti notoriamente riutilizzano le password per più sistemi.

Hanno specificamente raccomandato alle organizzazioni di adottare alcuni semplici passaggi per prevenire semplici attacchi di password.

Esistono diversi tipi di attacchi informatici che sfruttano le password deboli e gli utenti che utilizzano le password su più siti:

Brute Force Attacks – Attacchi che provando combinazioni casuali di caratteri e numeri per “indovinare” le credenziali per l’accesso di un utente. Fondamentalmente bombardano una pagina di accesso con possibili credenziali fino a quando non hanno successo. Meno complessa è la password di un utente, più è probabile che un attacco di forza bruta abbia successo.
Dictionary Attacks – Gli attacchi con dizionario utilizzano password note, password comunemente utilizzate per cercare di “indovinare” la password di un utente e accedervi. Il fatto che molti utenti utilizzino password come “12345678” o “password” rende efficaci gli attacchi con dizionario.
Credential Stuffing – Questo tipo di attacco, utilizza nomi utente e password noti che sono stati violati per accedere agli account. Poiché è probabile che gli utenti utilizzino le stesse credenziali come un particolare indirizzo e-mail e una password significativa per più applicazioni, il Credential Stuffing è abbastanza efficiente. Quest’anno è stato scoperto un database COMB, o Compilation of Many Breaches, con oltre 3,2 miliardi di combinazioni di nome utente e password ottenute da violazioni precedenti. Questi dati sono disponibili sul dark web per essere utilizzati dai criminali informatici a loro piacimento.

La pubblicazione speciale NIST 800-63B, Digital Identity Guidelines: Authentication and Lifecycle Management, raccomanda che “le password scelte dagli utenti vengano confrontate con una “blacklist” di password inaccettabili. Questo elenco dovrebbe includere password di precedenti corpus di violazioni, parole del dizionario e parole specifiche (come il nome del servizio stesso) che è probabile che gli utenti scelgano”. Implementando questo tipo di controllo sulle password degli utenti, si porranno delle barriere formidabili contro i 3 tipi di attacchi di password descritti sopra.

SmartFactor Authentication di OneLogin può garantire che gli utenti non utilizzino password o credenziali facili da indovinare che sono state rubate da altri sistemi. SmartFactor Authentication include due opzioni che soddisfano queste raccomandazioni NIST:

Dynamic Password Blacklist
Consente agli amministratori di impedire agli utenti di utilizzare particolari password comuni o addirittura come parte di una password. Ad esempio, puoi bloccare l’utilizzo di “password” e “password123” o qualsiasi altra password con la parola “password” al suo interno, impedendo anche di utilizzare alcuni dei propri dati, come il nome o l’azienda per cui lavorano, all’interno della password.

Compromised Credential Check
Confronta le credenziali degli utenti (sia nome utente che password o anche solo la loro password) con elenchi di credenziali note violate. Ciò renderebbe gli elenchi (come il database COMB) inutili per i criminali informatici da utilizzare per violare il sistema.

Dobbiamo tutti essere più vigili come amministratori, sviluppatori e utenti nella protezione dei nostri dati e dei nostri sistemi. Sebbene i tipi di protezione che abbiamo descritto qui, come l’implementazione di un controllo delle credenziali compromesse, non siano richiesti in tutti i settori o in tutti i paesi, prevenire le violazioni degli utenti può farti risparmiare tempo e denaro a lungo termine. Seguire raccomandazioni e linee guida come quelle del NIST aiuterà a fare i primi passi.

Vai al post originale

Perimeter81 riceve l’Advanced AWS Technical Validation

da Domenico Panetta | Lug 6, 2021 | Notizie dal Mercato

Perimeter81 riceve l’Advanced AWS Technical Validation diventando Advanced Technology Partner nella rete di partner di Amazon Web Services.

Perimeter 81, fornitore leader di tecnologia Cloud VPN e Software Defined Perimeter, è stato riconosciuto come Advanced Technology Partner nell’Amazon Web Services (AWS) Partner Network (APN).

Informazioni su APN Technology Partners
L’APN è un programma globale, progettato per aiutare i partner APN a creare attività o soluzioni di successo basate su AWS fornendo supporto commerciale, tecnico, di marketing e go-to-market.
Questa distinzione riconosce che Perimeter 81 offre una soluzione software avanzata che ha dimostrato comprovata esperienza, competenza tecnica e si integra direttamente con la piattaforma AWS.
Inoltre, in qualità di partner APN, la soluzione di Perimeter 81 è sicura, conforme, segue l’AWS Well-Architected Framework e implementa le migliori pratiche di sicurezza, alta disponibilità, supporto, costi e automazione su AWS.

Perché lavorare con un partner APN?
I partner APN hanno una comprovata e profonda esperienza su AWS, il che significa che sono pienamente in grado di assistere durante la transizione al cloud. Con l’accesso completo ai vantaggi aziendali che AWS ha da offrire, i partner APN sono in grado di aiutare i clienti ad avere successo durante il loro viaggio e aiutarli a raggiungere i loro obiettivi aziendali.
Per Perimeter 81, questo risultato avvantaggia i propri clienti e partner attuali e futuri, migliorando la capacità di fornire una soluzione di accesso alla rete sicura di nuova generazione ai clienti che utilizzano AWS.

“Siamo orgogliosi di entrare a far parte dell’AWS Partner Network e siamo entusiasti di essere stati aggiunti come AWS Advanced Technology Partner”

ha affermato Amit Baraket, CEO e co-fondatore di Perimeter 81.

“Ci impegniamo a semplificare la sicurezza del cloud con un facile utilizzo di una soluzione software disponibile per aziende di tutte le dimensioni e speriamo che questo riconoscimento continui a spingerci avanti in questo mercato in rapida crescita”.

Perimeter 81 per AWS
Perimeter 81 offre Cloud VPN for AWS e sono responsabili dell’utilizzo sicuro dei servizi AWS non gestiti. Ciò significa che i clienti devono fornire la propria sicurezza attraverso l’autenticazione e il controllo dell’accesso degli utenti per proteggere il proprio ambiente cloud Amazon.
Comprendono l’impatto della migrazione al cloud, motivo per cui vogliono offrire una soluzione di sicurezza cloud scalabile e facile da usare, che fornisce controllo e monitoraggio degli accessi semplici ed economici per l’intero panorama della sicurezza

Le funzioni di sicurezza avanzate di Perimeter 81 includono:

Cost-Effective Compliance
Segmented Resource Access
Actionable Intelligence
Simple Cloud Migration
End-to-End Encryption
Secure Remote Access

Informazioni sul Perimeter 81
Perimeter 81 è un provider di sicurezza di rete software-defined di nuova generazione, guidato dalla missione di trasformare l’accesso alla rete sicuro per la forza lavoro moderna e distribuita. Costruito da zero in base al contributo dei leader della sicurezza che necessitano di un cambiamento rispetto alla tecnologia VPN legacy, l’interfaccia intuitiva di Perimeter 81, la gestione unificata e l’integrazione perfetta con i principali servizi cloud, offrono alle aziende di tutti i settori e dimensioni il potere di essere completamente mobili e con sicurezza cloud-based. Contattaci per saperne di più e per scoprire come semplificare l’accesso sicuro all’intera rete AWS.

Vai al post originale

« Post precedenti

L’acquisizione supporta l’investimento dell’azienda in capacità di intelligence sulle minacce predittive in tempo reale per una difesa proattiva contro le minacce emergenti.

Utilizza comunque le password?

Fornisce MFA passwordless per l’accesso desktop?

È una soluzione certificata FIDO o FIDO2 dall’inizio alla fine?

La soluzione è in grado di interagire ed integrarsi con il tuo Identity Provider (IdP)?

È facile da integrare e distribuire?

Com’è l’esperienza dell’utente?

Come vengono archiviate le chiavi private sui dispositivi?

Cos’è un brute force attack?

Come rilevare un brute force attack

4 modi per prevenire un brute force attack.

Utilizzare password complesse e la loro scadenza.

Bloccare (anche temporaneamente) gli account dopo un numero ragionevole di tentativi falliti.

Implementare l’autenticazione a più fattori (MFA).

Verificare la presenza di credenziali compromesse.

Che cos’è la Cyber Liability Insurance (Assicurazione di Responsabilità Informatica)?

Comprensione del requisito MFA di assicurazione informatica

Perché gli assicuratori richiedono l’MFA?

Cosa impedisce alle aziende di implementare l’MFA?

L’autenticazione passwordless soddisfa i requisiti MFA della Cyber ​​Insurance?

Soddisfa il mandato di MFA di Cyber Insurance in modo indolore

Cos’è un DNS? E dove si adatta Microsoft Azure?

Cos’è il filtro DNS di Azure?

DNS Filtering basato su Azure Active Directory (AAD)

Vantaggi dell’utilizzo del filtro DNS di Azure

Motivi per implementare una Log Collection

Guida al logging dal settore Industry

WebTitan Cloud vs Cisco Umbrella

WebTitan Cloud vs Cisco Umbrella: Differenze Chiave

Costo e prezzo

Interfaccia utente e reportistica

Flessibilità

Supporto

Cloud Keys

Capacità On premise

Possibilità di personalizzare la soluzione

Quali sono i tipi comuni di attacchi di minacce avanzate?

Che cos’è l’Advanced Threat Protection di Office365?

Come implementare un Advanced Threat Defense?

Search

Categorie

L’autenticazione passwordless soddisfa i requisiti MFA della Cyber Insurance?