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

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

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:

  1. I tipi di eventi DNS da loggare (query only, query e risposta)
  2. Quanto sono dettagliati gli eventi (ad esempio verbose)
  3. 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:

  1. Quali informazioni di monitoraggio su DNS e domain activity possono essere ottenute dalle source esistenti?
  2. Quali aree devono essere ampliate per migliorare la visibilità dei log, in particolare per i metadati contenenti log di dominio e DNS?
  3. Quali altre opportunità ci sono per aumentare l’ambito complessivo della raccolta dei log?
  4. Quale di queste source porta a una migliore intelligenza per i tuoi casi d’uso?
  5. 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.

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

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

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.

  1. 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.
  2. 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à.
  3. 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.
  4. 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.
  5. 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.
  6. 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.
  7. 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.
  8. 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

Massimizzare le difese con la log collection DNS in Windows

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:

 

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:

  1. Quali informazioni di monitoraggio su DNS e attività del dominio possono essere ottenute dalle fonti esistenti?
  2. Quali aree devono essere ampliate per migliorare la visibilità dei log, in particolare per i metadati contenenti log di dominio e DNS?
  3. Quali altre opportunità ci sono per aumentare l’ambito complessivo della raccolta dei registri?
  4. Quale di queste fonti porta a una migliore intelligence per i propri casi d’uso?
  5. 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.

Come la Log Collection rafforza le difese con DomainTools

Come la Log Collection rafforza le difese con DomainTools

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.

Come la Log Collection mirata rafforza le difese

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.

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

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

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.

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

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

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 InsightIDR), e pubblicheremo una serie su Server DNS Linux e Windows e il deployment della log collection dei client, così come altre sorgenti di log (cloud, auditing, mail log, network defense log e altro ancora).

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

Motivi per implementare una Log Collection

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

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

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

Guida al logging dal settore Industry

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

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

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

Configurazione di esempio dalla NSA Event Monitoring Guidance:

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

 

OWASP (Open Web Application Security Project)

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

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

SANS Critical Controls

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

Open Source

SwiftonSecurity Github Repo for Sysmon

Altre indicazioni: Indicazioni generali sulla raccolta dei log

 

Numeri di Log Deployment: Uno scenario

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

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

Esempio di deployment di istanze Splunk

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

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

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

Un esempio di deployment: Potential Logging Stats

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

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

Dove:

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

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

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

 

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

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

Sulla base dei nostri calcoli:

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

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

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

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

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

Conclusione

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

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

Sfruttare i Log dalla sorgente al SIEM (e altro)

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

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

WebTitan Cloud vs Cisco Umbrella

WebTitan Cloud vs Cisco Umbrella

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

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

  • 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.

Rapid7 acquisisce IntSights, leader nell’intelligence sulle minacce

Rapid7 acquisisce IntSights, leader nell’intelligence sulle minacce

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.

SpamTitan & Office365 Advanced Threat Protection

SpamTitan & Office365 Advanced Threat Protection

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).

I Remote Worker mettono a rischio la sicurezza informatica

I Remote Worker mettono a rischio la sicurezza informatica

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

Il NIST dice no, alle credenziali compromesse

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.

Perimeter81 riceve l’Advanced AWS Technical Validation

Perimeter81 riceve l’Advanced AWS Technical Validation

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:

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.

Un nuovo modo per individuare le infrastrutture pericolose

Un nuovo modo per individuare le infrastrutture pericolose

DomainTools, si occupa da sempre, di aiutare i difensori, i soccorritori e altri professionisti di infosec a individuare e caratterizzare le infrastrutture online pericolose, ed oggi sono lieti di condividere alcuni dettagli su due nuove offerte, che aiuteranno in questo: IP Hotlist e Hosting IP Risk Feed.

Questa non è la loro prima incursione nel risk scoring, ovviamente; il Domain Risk Score è in produzione da diversi anni e viene utilizzato da team di tutto il mondo per qualsiasi cosa, dalla valutazione degli avvisi, alle liste di blocco della sicurezza della rete, fino alla guida alle indagini. Non appena hanno rilasciato il Domain Risk Score (beh, tecnicamente, anche prima di rilasciarlo!), hanno ricevuto una domanda molto logica: è possibile fare la stessa cosa per gli indirizzi IP?

Ora la risposta è “sì”, con l’importante condizione che la lente attraverso la quale valutano gli indirizzi IP siano i domini ospitati su di essi (quindi, ad esempio, questi prodotti non sono progettati per catturare indirizzi IP residenziali che vengono reclutati nelle botnet). Diamo un’occhiata a cosa sono questi due prodotti correlati al rischio IP ma diversi tra loro.

Hotlist IP

Dalla prevenzione al rilevamento e alla mitigazione, molte tecnologie di sicurezza in tutto lo spettro si concentrano sull’indirizzo IP come oggetto per la creazione delle regole. Se stai utilizzando quel tipo di attrezzatura, e se sei un professionista di infosec (sicuramente lo sei), hai bisogno di dati affidabili su cui costruire regole di blocco o rilevamento per gli indirizzi IP. La Hotlist IP è progettata per identificare la popolazione più rischiosa di indirizzi IP di hosting. Due criteri principali definiscono questo elenco: la percentuale di domini dannosi noti ospitati e previsti, e il livello di traffico che l’indirizzo sta ricevendo (in particolare per i domini ad alto rischio), commisurato alla raccolta Passive DNS a livello di Internet. La Hotlist è un database ideale per l’elenco dei blocchi ad alta affidabilità e le regole di rilevamento. La dimensione tipica della hotlist è compresa tra 40.000 e 60.000 indirizzi IP.

Cosa determina il modo in cui un indirizzo IP viene inserito nella Hotlist? Quello a cui DomainTools vuole arrivare, sono quei domini che sono sia ostili che attivi. Ci sono molte infrastrutture ostili ma dormienti là fuori. Sebbene sia ancora importante sapere, da un punto di vista investigativo, i più critici “devo-preoccuparmi-di-questo” IP, sono quelli che sono controllati da attori malintenzionati e stanno ricevendo traffico, presumibilmente dagli ambienti della vittima. In DomainTools sono particolarmente orgogliosi della combinazione riuscita del punteggio di rischio e degli eccezionali dati pDNS che ottengono da Farsight Security e dagli altri provider pDNS.

Hosting IP risk feed

Ecco una piccola sbirciatina dietro le quinte di DomainTools: molte discussioni sono state fatte, per capire se avesse senso chiamare questo prodotto “Risk Feed” e non qualcos’altro, perché, a differenza della Hotlist, gli indirizzi IP in questo feed non sono necessariamente rischiosi. L’Hosting IP Risk Feed è un feed giornaliero di tutti gli indirizzi IP trovati ad ospitare almeno un dominio. Quindi, a differenza della Hotlist IP, questo feed include qualsiasi IP che ospita attivamente, indipendentemente dal suo livello di rischio. Ma poiché viene inclusa ancora la percentuale di domini dannosi noti e previsti per ciascun IP nel feed, è stato ritenuto che il suo orientamento fosse basato sulla questione del rischio, da cui il nome. Ma c’è molto di più che solo indirizzi e punteggi di rischio: Hosting IP Risk Feed contiene anche campi di dati dettagliati che arricchiscono l’IP. In definitiva, nessuno è in una posizione migliore di te stesso, per decidere cosa costituisce un rischio elevato nel tuo particolare ambiente, quindi Hosting IP Risk Feed fornisce gli elementi costitutivi per creare un elenco IP altamente personalizzato in base ai propri criteri. Ad esempio, si potrebbe avere un interesse significativo per la geolocalizzazione IP, forse per la propria organizzazione, il traffico verso gli IP in determinate regioni sarà sempre considerato ad alto rischio, indipendentemente da altri criteri. L’Hosting IP Risk Feed consentirà di creare rilevamenti o blocchi basati su questo. O forse si potrebbe voler combinare vari campi, come Paese, ASN, Domain Risk Score, ecc., per le proprie regole. L’ampiezza dei dati nel feed lo rende una semplice questione di scripting contro il feed (che è un semplice file flat).

DomainTools è lieta di presentare questi importanti strumenti nella lotta contro le infrastrutture online ostili, e se desideri saperne di più su IP Hotlist o Hosting IP Risk Feed, contattaci.

Packets vs Flow/IPFIX – Lo sforzo per ridurre il dwell time

Packets vs Flow/IPFIX – Lo sforzo per ridurre il dwell time

Al giorno d’oggi, quando sentiamo parlare di un attacco informatico, c’è spesso un riferimento a quando la rete è stata originariamente compromessa, poichè negli ultimi anni, la necessità di determinare da quanto tempo quella compromissione è stata presente (dwell time), chi altro era coinvolto e come si è ottenuta tale accesso, si è spostata in prima linea nelle esigenze del team SecOps.

Che cos’è il dwell time (tempo di permanenza) e perché è importante ridurlo?
Il dwell time rappresenta il periodo di tempo in cui un hacker ha campo libero su una rete compromessa, fino a quando non viene eliminato. Questo tempo, viene determinato aggiungendo il Mean Time To Detect (MTTD) e il Mean Time to Repair/Remediate (MTTR), e viene solitamente misurato in giorni, sebbene in genere duri settimane o addirittura mesi. Inutile dire che ridurre il tempo di permanenza delle violazioni informatiche è essenziale per limitare l’infiltrazione nella rete e la responsabilità finanziaria, ma la questione di come affrontarla al meglio diventa complicata.

Quindi, come possiamo aumentare la visibilità e ridurre questo tempo?
Un approccio comune per ottenere visibilità sulla rete consiste nell’implementazione di una soluzione di packet capture in punti strategici, come il perimetro Internet e il perimetro Data Center, questo è comunemente indicato come traffico Nord/Sud (traffico in entrata e in uscita dal perimetro di rete aziendale), il problema con questo approccio è che tocca solo una piccola parte del traffico di rete.

Già nel 2014 Cisco ha chiarito questo punto osservando che il 76% del traffico attraversava il data center in direzione Est/Ovest (traffico interno alla rete e che non esce dal perimetro, ovvero comunicazioni Client-Server e Server-Server), mentre solo il 17% del traffico si spostava in direzione nord/sud in quel momento. Ciò significa che l’approccio perimetrale alla sicurezza informatica “fossato e mura del castello” chiaramente non è sufficiente e qualsiasi rilevamento basato su questo modello non riuscirà a trovare infiltrazioni o movimenti laterali, finché qualcosa non attraversa un confine monitorato. In effetti, i recenti attacchi ransomware aiutano a consolidare la necessità di una maggiore visibilità est/ovest poiché il loro approccio “basso e lento” tende a non toccare il perimetro fino a quando l’incidente non si è intensificato.

Come menzionato in altri blog, ci sono ragioni legittime per implementare una soluzione di packet capture; ad esempio, quando la conformità normativa lo richiede. La sfida con l’espansione di questo approccio su tutta la rete è che il modello di distribuzione è complesso e richiede cose come Tap e Network Packet Broker (NPB). Poiché la scala delle reti odierne e l’ottenimento di questo livello di visibilità è enorme e sembra crescere ogni giorno, le aziende stanno esplorando altri approcci, che possano fornire visibilità dettagliata, scalabilità e riduzione del costo totale di proprietà dell’attuale implementazione di rete.

Il Global Cloud Index di Cisco afferma che, a differenza delle reti dei campus, il volume di traffico dominante nel Data Center attraversa una direzione “Est-Ovest”.

Munawar Hossain, Cisco

Perché NetFlow e IPFIX sono una scelta migliore?
Esistono diversi motivi per considerare NetFlow/IPFIX per ottenere una migliore visibilità sul traffico di rete. Innanzitutto, fornisce oltre il 90% del contesto per il quale la maggior parte dei professionisti IT si rivolge all’analisi dei pacchetti. Inoltre, l’adozione è aumentata e ora tutti i principali fornitori supportano NetFlow e IPFIX. Alcuni degli odierni strumenti di reporting NetFlow migliorano persino i dati con cose come l’integrazione di Active Directory e il reporting dei nomi utente e, a loro volta, forniscono maggiori dettagli a un costo inferiore.

In secondo luogo, la tecnologia è super scalabile. Poiché si stanno utilizzando i propri dispositivi di rete, è relativamente facile iniziare il monitoraggio, basta configurare il flusso da inviare dal dispositivo al Collectore, per avere immediata visibilità di un punto oscuro della rete. Il Collector è dove avviene la magia poichè dà la possibilità di correlare le conversazioni, fornire informazioni forensi e monitorare il traffico con intelligenza.

Terzo, riduce il costo totale di distribuzione e proprietà. Nella maggior parte dei casi si ha già l’attrezzatura, e l’utilizzo delle risorse che già si possiedono non solo fornisce le informazioni necessarie per la “riduzione del dwell time”, ma fornisce anche prove forensi dettagliate per tutti gli strumenti di monitoraggio. Ciò consente di fornire un contesto a tali avvisi e aiuta a proteggere più di un singolo punto sulla rete.

Pronto a ridurre il tempo di permanenza?
Il mondo come lo conosciamo è cambiato e continuerà su questa strada. Tutti sanno che è necessario ridurre il tempo di permanenza di un’intrusione nella rete, il concetto è semplice, ma in che modo l’azienda implementerà questo requisito? Come detto prima, l’utilizzo di metadati avanzati come NetFlow e IPFIX espanderà immediatamente la visibilità, raccoglierà quei dati in modo realistico e scalabile e lo farà a un costo molto inferiore. Non ci credi? Se stai cercando una soluzione NDR che offra un’ampia visibilità delle conversazioni oltre a fornire la flessibilità necessaria per integrare tali dati nel proprio ambiente, perché non valutare Scrutinizer?

Contattaci per avere maggiori informazioni.

Rapid7 e Velociraptor uniscono le forze

Rapid7 e Velociraptor uniscono le forze

Notizie entusiasmanti! Rapid7 e Velociraptor uniscono le forze un framework di Digital Forensics and Incident Response (DFIR), è un progetto open source che consente la ricerca su migliaia di host per fornire dati fruibili in pochi minuti e una visibilità senza precedenti sullo stato degli endpoint.

Un attacco informatico può interrompere le operazioni per ore, giorni o settimane e causare danni collaterali e perdite di informazioni che possono durare anche più a lungo. Troppo spesso, le organizzazioni non si rendono conto di essere state violate fino a quando l’ambiente IT non viene infettato o i dati vengono compromessi o persi.

Velociraptor è stato introdotto solo pochi anni fa, sviluppato da Mike Cohen, uno specialista di sicurezza delle informazioni in digital, network e memory forensics, insieme ai suoi colleghi collaboratori della community. In Google, Mike ha lavorato su strumenti a supporto del team di risposta agli incidenti, tra cui advanced incident response e remote forensics tool Google Rapid Response (GRR), memory analysis e forensic framework Rekall. Ora, Mike si unisce al team di Detection and Response di Rapid7, dove riceverà il supporto per costruire ed espandere ulteriormente la community di Velociraptor.

Rapid7 crede fermamente nel software e nelle community open source poiché consente un time-to-market più rapido, amplia l’accesso all’innovazione e aumenta la produttività. Rapid7 ha una storia di investimenti, contributi e sviluppo sull’open source. Iniziatndo ad investire nella community open source 12 anni fa, quando Rapid7 ha acquisito Metasploit. Da allora, Metasploit ha continuato a prosperare ed è uno dei progetti e delle community di sicurezza offensiva open source più costantemente attivi al mondo. Hanno anche creato AttackerKB, una piattaforma guidata dalla community in cui i professionisti della sicurezza possono scambiare informazioni sulle vulnerabilità per comprendere meglio l’impatto e la probabilità di essere sfruttati, e Recog, che aiuta i professionisti della sicurezza a gestire il rischio che i dispositivi connessi a Internet, possono introdurre dando loro visibilità su quale tecnologia è presente nei loro ecosistemi.

Mentre assume la gestione del progetto Velociraptor, Rapid7 vuole che la community sappia del loro impegno ad aiutarli a crescere e prosperare attraverso eventi, progetti, impegno, contributi e altro ancora. Hanno inoltre in programma di incorporare il progetto Velociraptor nella piattaforma Rapid7 Insight, consentendo ai clienti di beneficiare di questa straordinaria tecnologia e community.

L’offerta autonoma Velociraptor consente ai team di incident response, di raccogliere ed esaminare rapidamente gli artefatti da una rete e fornire dettagli forensi a seguito di un incidente di sicurezza. In caso di incident, un investigatore controlla gli agenti Velociraptor per individuare attività dannose, eseguire raccolte mirate, eseguire analisi di file o estrarre campioni di dati di grandi dimensioni. Il Velociraptor Query Language (VQL) consente agli investigatori di sviluppare hunt personalizzate per soddisfare esigenze di indagine specifiche.

Gli utenti beneficiano di:

  • Accesso a una soluzione open source gratuita. Il minor costo di proprietà è stato uno dei motivi principali per cui le organizzazioni hanno preso in considerazione il software open source.
  • Analisi forense all’endpoint. VQL consente di eseguire analisi automatizzate e chirurgiche sull’endpoint, individuando le minacce su larga scala in pochi minuti senza influire sulle prestazioni dell’endpoint.
  • Condivisione della conoscenza. Le query condivise all’interno della community consentono agli utenti meno qualificati di sfruttare le query scritte da esperti DFIR.
  • Raccolta chirurgica, velocità e scalabilità. Effettuare il triage efficiente e analizzare rapidamente le prove forensi per determinare rapidamente la root cause.
  • Mean Time To Detect (MTTD) e Mean Time To Respond (MTTR) accelerati. La caccia proattiva su larga scala in pochi minuti consente agli utenti di eseguire rapidamente interventi tattici e rimedi, limitando potenziali danni.
  • Supporto per Linux, Windows e macOS.
  • Potente linguaggio di query VQL. Gli investigatori definiscono artefatti per raccogliere e ricercare gli endpoint senza la necessità di modificare il codice sorgente o distribuire software aggiuntivo, adattando rapidamente le query in risposta alle minacce mutevoli e alle nuove informazioni ottenute attraverso l’indagine.

Non ci sono piani per Rapid7 per rendere Velociraptor un’offerta commerciale; tuttavia, prevedono di sfruttare la tecnologia nel loro portafoglio di detection and response. Come primo passo per l’integrazione di Velociraptor nella piattaforma Rapid7 Insight, hanno già incorporato le capacità di raccolta dei dati degli endpoint di Velociraptor nell’Insight Agent, risparmiando tempo critico mentre il team MDR passa dal monitoraggio del proprio ambiente alla risposta a un incidente. Gli analisti MDR di Rapid7 possono cercare attivamente attività sospette utilizzando una libreria di query Velociraptor VQL che possono essere personalizzate in base a specifiche esigenze di caccia alle minacce. Se si verifica un evento grave su un endpoint, gli analisti MDR possono attivare una risposta automatica per raccogliere prove, interrompere silenziosamente l’attività dannosa o bloccare completamente endpoint e account.

Non vedono l’ora di fidanzarci con la community Velociraptor. La partecipazione di Rapid7 permetterà di scoprire le esigenze e sperimentare soluzioni su larga scala; raccogliere input per aggiornare e migliorare il codice; crowdsourcing di nuovi requisiti, casi d’uso e idee di funzionalità per offerte commerciali e non.

Rapid7 ritiene inoltre di poter promuovere la community e aumentare la partecipazione all’ecosistema Velociraptor. Inizia da ora e scarica Velociraptor da GitHub e facci sapere cosa ne pensi!

Puoi anche controllare il blog di Mike sul sito della community di Velociraptor.

Deploy dei PC con Faronics Deploy e Deep Freeze Cloud

Deploy dei PC con Faronics Deploy e Deep Freeze Cloud

L’installazione, la distribuzione e la configurazione del Sistema Operativo e degli applicativi (deployment) sui PC degli utenti, è forse il processo più importante ed oneroso, sia in termini di tempo che di risorse (umane e non) investite dal reparto IT di un’azienda, la suite Faronics (Deploy e Deep Freeze) consente di automatizzare completamente questo processo, consentendo di ridurre al minimo le attività.

Faronics, offre una suite di prodotti offerti come Software-as-a-Service (SaaS) che, oltre al reboot-to-restore brevettato, consente Asset Management, Software Deployment, Patch Management, Sicurezza Multi Layer, OS Deploy, Controllo Remoto, Gestione dell’alimentazione e altro ancora, permettendo di controllare tutte le risorse IT da un’unica console unificata, sempre e ovunque che, oltre a consentire un processo di re-imagin vero e proprio, consente tramite i suoi strumenti e automatismi di configurare nuovi PC con software, driver e configurazioni personalizzate, il tutto tramite tecnologia Cloud.

Faronics Deploy - Compre agora na Software.com.br

Come funziona?

Una volta connesso un nuovo PC in rete, sarà possibile eseguire il deploy del Sistema Operativo tra quelli precedentemente preparati tramite cattura dell’immagine o installazione vera e propria, consentendo la Join a dominio, l’installazione dei software aziendali necessari, dei driver specifici e la personalizzazione di qualsiasi aspetto dell’intero Sistema Operativo, come ad esempio WiFi, VPN e altre impostazioni definite, permettendo che il PC non debba neanche passare dall’ufficio IT per la preparazione.

Come si configura?

È difficile fornire una spiegazione dettagliata di tutti i passaggi in un breve articolo, ma volendo fornire delle indicazioni di alto livello, possiamo riassumere in questi 3 step:

  1. Configurare sulla Console SaaS, tutte le personalizzazioni richieste (software, lingua, patch, chiavi di registro, driver etc etc).
  2. Accendere il PC collegato alla rete.
  3. Attendere il completamento del Deploy.

Di recente è stata inoltre aggiunta una nuova funzionalità a Faronics Cloud Deep Freeze, che consente di memorizzare l’immagine in locale, in modo che il dispositivo non debba connettersi al server di imaging per scaricare nuovamente l’intera immagine durante il processo di reimaging, consentendo di ripristinare l’immagine di un PC, senza che questo passi dall’Ufficio IT, permettendo di farlo da qualsiasi posizione, purché il computer comunichi con il servizio cloud.

Molti gestiscono questo genere di attività manualmente o quasi, impiegando diverse risorse e lunghi tempi di attesa per la preparazione di un PC, il tempo di SysAdmin o dei membri dello staff di Help Desk è prezioso e potrebbe essere dedicato a operazioni più complesse e prioritarie rispetto ad operazioni ripetitive e a basso valore. Le soluzioni Faronics consentono quindi di automatizzare e semplificare il processo di deployment, sgravando i Team IT da queste attività.

Quali potrebbero essere dei buoni motivi per adottare le soluzioni Faronics?

  • Sfruttando l’installazione automatica di Sistema Operativo e applicazioni, la gestione dei driver e la personalizzazione di tutto ciò che serve all’interno di un’azienda è possibile risparmiare moltissime ore di tempo.
  • Nessuna soluzione OnPrem da mantenere e gestire, eliminando le dipendenze interne.
  • I PC possono essere preparati e ripristinati indipendentemente dalla loro posizione, consentendo di gestirli da un’unica console Cloud.

 

Cosa serve per iniziare ad utilizzare i prodotti Faronics?

Nulla, solo avviare una trial 30 giorni di Faronics Deploy o Deep Freeze Cloud ed iniziare a usarlo, oppure contattaci.

MITRE ATT&CK – ReaQta Hive ottiene il 100% di Detection Coverage

MITRE ATT&CK – ReaQta Hive ottiene il 100% di Detection Coverage

Per le valutazioni del “MITRE Engenuity 2020”, nella quale ReaQta ottine il 100% di Detection Coverage, MITRE ha scelto di valutare due noti attori di minacce: Carbanak e FIN7, mentre la valutazione dello scorso anno, riguardante APT29, era incentrata sullo spionaggio governativo, quest’ultimo round si è concentrato su attori di minacce motivati finanziariamente e ha incluso, per la prima volta, test su endpoint Windows e Linux,

Entrambi i gruppi di minacce sono noti per il loro mestiere, efficienza e furtività, nonché per l’utilizzo di molte tecniche avanzate per esfiltrare dati preziosi dalle loro vittime.

Le banche erano l’obiettivo principale di Carbanak, mentre FIN7 si rivolge principalmente al settore della vendita al dettaglio, della ristorazione e dell’ospitalità negli Stati Uniti.

Sono state impostate ed eseguite due sofisticate emulazioni dell’avversario per testare le capacità dei difensori di identificarli e seguirli. Come la precedente edizione APT29, ReaQta-Hive ha mostrato le sue capacità Best-in-Class e ha fornito risultati impressionanti.

I risultati di ReaQta, sia su Windows che su Linux, nella valutazione di quest’anno includono:

  • Copertura di rilevamento del 100% su tutta la cyber kill chain.
  • Nessuna modifica alla configurazione durante l’intera valutazione.
  • Rilevamenti in tempo reale al 100% senza delay nei rilevamenti.

I risultati dimostrano le capacità di ReaQta-Hive di fornire una copertura completa dagli attacchi sofisticati, senza intervento umano, producendo al contempo la quantità minima di avvisi ad alta fedeltà senza falsi positivi.

Come è successo durante il Round 2 della valutazione MITRE, il suo NanoOS™, l’hypervisor live utilizzato per rilevare comportamenti dannosi di alto livello, non ha potuto essere utilizzato a causa di restrizioni nell’ambiente di test. Tuttavia, la piattaforma ha funzionato molto bene, anche senza il suo componente principale.

Copertura di rilevamento del 100% lungo tutta la catena di cyber kill

In entrambi gli scenari Cabarnak e FIN7, ReaQta-Hive è stato in grado di rilevare autonomamente il 100% delle attività lungo la cyber kill chain e ha fornito all’utente avvisi ad alta fedeltà con informazioni significative e fruibili, definendo chiaramente i passaggi successivi.

Perché questo è importante?

I nostri clienti preferiscono meno avvisi altamente consolidati rispetto a quelli multipli e meno informativi. Questo approccio riduce costantemente il carico di lavoro manuale e fornisce un quadro chiaro degli eventi che si stanno verificando, senza la necessità di inseguire gli aggressori per centinaia o addirittura migliaia di diversi eventi di sicurezza.

Rilevamenti completamente autonomi al 100%

Solo pochi fornitori sono riusciti a ottenere un tasso di rilevamento del 100%, lungo l’intera cyber-kill chain, senza modifiche alla configurazione, ReaQta è uno di loro. Le modifiche alla configurazione aiutano i fornitori a modificare i propri rilevamenti man mano che l’attacco progredisce. Tuttavia, negli scenari di vita reale, una modifica della configurazione di solito non è realistica poiché gli aggressori non danno ai difensori una seconda possibilità di modificare i loro rilevamenti prima di passare al passaggio successivo. In ReaQta, per garantire una valutazione equa delle nostre capacità di rilevamento, abbiamo deciso, come previsto, di non alterare la configurazione iniziale della nostra piattaforma.

Perché questo è importante?

Le modifiche alla configurazione presuppongono la conoscenza preliminare di un attacco, il che non è il caso nella maggior parte degli scenari. Se una piattaforma richiede diverse modifiche alla configurazione per funzionare alla massima efficienza, o anche solo per rilevare una minaccia attiva, le sue capacità di rilevamento autonomo sono inevitabilmente compromesse, così come la capacità di rispondere in tempo reale.

100% dei rilevamenti effettuati in tempo reale senza ritardi

Tutti i rilevamenti di ReaQta-Hive erano interamente in tempo reale, collocando ReaQta tra i pochissimi fornitori in grado di farlo. I motori di analisi comportamentale al centro di ReaQta-Hive lo hanno reso possibile, assicurando che ogni fase dell’attacco fosse tracciata come -happened, riducendo al minimo il rischio di perdere eventi importanti in attesa che componenti esterni eseguano le proprie analisi.

Perché questo è importante?

Man mano che gli hacker si innovano, sempre più passaggi vengono automatizzati. L’automazione consente agli aggressori di muoversi in amnieta estremamente veloce all’interno di una rete: le operazioni che prima richiedevano minuti o ore solo pochi anni fa, ora avvengono in pochi secondi. Un’identificazione immediata e una risposta automatizzata tracciano il confine tra un’infrastruttura completamente compromessa e una violazione non riuscita.

Fornire sicurezza senza complessità

La piattaforma di intelligence sulla difesa attiva di ReaQta, ReaQta-Hive, mira a risolvere il crescente numero di aziende vittime di attività dannose da parte di criminali informatici. Mentre i metodi di protezione tradizionali combattono le minacce note e sono vulnerabili a tecniche di attacco sofisticate, la piattaforma rivoluzionaria di ReaQta blocca le minacce note e sconosciute in tempo reale. Attraverso il deep learning, la piattaforma migliora costantemente nella definizione del comportamento normale su misura per ogni azienda per endpoint, consentendo di bloccare qualsiasi comportamento anomalo.

Inoltre, le soluzioni tradizionali richiedono che i team di sicurezza informatica interni o esterni agiscano su qualsiasi minaccia segnalata. La piattaforma di ReaQta non solo rileva le minacce, ma consente anche una risposta alle minacce senza soluzione di continuità e automatizzata in tempo reale. ReaQta è stato recentemente nominato Cool Vendor 2020 da Gartner in Network and Endpoint Security per questo approccio unico nell’affrontare le minacce informatiche di tutte le forme.

Per saperne di più su ciò che rende ReaQta unico, guarda il nostro webinar oppure contattaci.

Da Yubico nuovo SDK (Software Development Kit) per integrazione Microsoft

Da Yubico nuovo SDK (Software Development Kit) per integrazione Microsoft

Yubico annuncia l’integrazione con Microsoft .NET grazie al suo nuovo SDK

Yubico annuncia la nuova SDK per integrazione con Microsoft – In continuità con la missione di divulgare la strong authentication nel mondo, Yubico è entusiasta di annunciare che l’integrazione di YubiKey nella applicazioni .NET o nel flusso di lavoro, sarà ora più facile che mai. Ciò è reso possibile dall’introduzione del nuovo YubiKey SDK for Desktop. Con questo Desktop SDK, è ora possibile aggiungere il supporto per YubiKey multiprotocollo direttamente nelle proprie applicazione, supportando scenari di autenticazione sia tramite USB che NFC.

La prima beta, rilasciata venerdì 18 Giugno 2021, supporta le applicazioni Initiative for Open Authentication (OATH) e Personal Identification and Verification (PIV), mentre a luglio verrà effettuato un aggiornamento beta che aggiungerà il supporto per l’applicazione Yubico OTP.

Per le organizzazioni che utilizzano YubiKey come Smart Card PIV, Desktop SDK automatizza molte attività come la generazione di coppie di chiavi, il caricamento di certificati e altro ancora. Insieme alla documentazione completa e al codice di esempio, Yubico dimostra come utilizzare l’SDK per la gestione e il provisioning delle Smart Card end-to-end.

Non importa come gli utenti interagiscono con YubiKey, l’esperienza dello sviluppatore è la stessa, e con il supporto NFC nativo, creare scenari “tap and go” per i flussi di lavoro basati su password una tantum, diventa facile come se fosse USB.

Funzionalità principali della nuova SDK Yubico per integrazione con Microsoft

  • Supporto per sistemi operativi macOS e Windows
  • NFC as a first-class citizen
  • Targets .NET Standard 2.0
  • Layered API: Utilizzare le API della sessione dell’applicazione per un rapido sviluppo dell’applicazione oppure utilizzare i comandi di basso livello per un controllo totale.

Entro la fine dell’estate, Yubico rilascerà la SDK Yubico per integrazione con Microsoft come progetto open source su GitHub.

Come iniziare

Come parte dello sforzo YubiKey SDK for Desktop, Yubico sta preparando la documentazione che è attualmente in versione Beta e continuerà ad essere ampliata e migliorata durante l’intero ciclo di rilascio dell’SDK.

L’SDK Desktop è disponibile oggi su NuGet.org nell’ambito dell’organizzazione Yubico, il pacchetto a cui fare riferimento è Yubico.YubiKey.

Come partecipare alla beta pubblica e fornire un feedback

Tutti gli utenti Yubico Mobile SDK esistenti e coloro che sono curiosi di integrare la sicurezza hardware nelle loro offerte desktop, sono invitati a partecipare al webinar che si terrà il 30 Giugno, per imparare come integrare le app desktop con Yubikeys, per fornire un feedback scrivi a desktopsdkbeta@yubico.com.

Bank of America protegge l’accesso e i trasferimenti finanziari con YubiKey

Bank of America protegge l’accesso e i trasferimenti finanziari con YubiKey

Sebbene ci siano state molte pietre miliari nell’ultimo decennio, oggi Bank of America segna un vero “passo avanti nella sicurezza” che protegge ulteriormente l’accesso al conto bancario online e i trasferimenti finanziari per i suoi clienti, poichè ha annunciato che stanno sostituendo SafePass con la nuova funzione Secured Transfer, che consente la registrazione della Security Key USB e l’autenticazione del trasferimento con YubiKey.

Bank of America ha una lunga storia nel supporto dell’autenticazione per l’esperienza bancaria online. E’ stata una delle prime grandi banche ad aderire alla FIDO Alliance e ad essere nominata nel suo consiglio di amministrazione nel 2014, nel 2016, hanno sostenuto, insieme a Yubico e molti altri, il lancio della campagna di sensibilizzazione pubblica “Lock Down Your Login” progettata per consentire a ogni americano di proteggere meglio i propri account online attraverso l’uso ella Strong Authentication, e

La protezione antifurto SafePass di Bank of America è stata originariamente introdotta per fornire ai clienti individuali, di piccole imprese e di intermediazione un ulteriore livello di sicurezza contro le transazioni non autorizzate. In precedenza, SafePass consentiva solo l’autenticazione mobile con codice una tantum o tramite carte SafePass. L’avanzamento di Bank of America alla funzione Secured Transfer si basa su questo, introducendo l’opzione per un’autenticazione hardware basata su FIDO e quidni più sicura.

Molti utenti di servizi bancari online di Bank of America che dispongono di una YubiKey, possono ora registrare la propria Security Key per l’autenticazione a due fattori di accesso all’account (2FA) e impostare la funzione di trasferimento protetto per aggiungere un ulteriore livello di sicurezza fisica al proprio account online.

Come proteggere l’accesso all’online banking ed i trasferimenti finanziari con la propria YubiKey:

  1. Accedere al conto online Bank of America utilizzando il proprio nome utente e password;
  2. Una volta effettuato l’accesso, andare su “Profile & Settings” nell’angolo in alto a destra e, in “Security settings”, fare clic su “Manage SafePass“;
  3. A seconda del tipo di account e/o delle impostazioni dell’account, è possibile vedere l’opzione per aggiungere una Security Key USB e abilitare il trasferimento protetto.

protegge accesso trasferimenti YubiKey

Una volta configurata la Security Key USB, quando verrà effettuato l’accesso al proprio account online o si esegue un bonifico bancario, verrà chiesto di toccare la tua YubiKey.

protegge accesso trasferimenti YubiKey

Quando viene toccata, la YubiKey esegue uno scambio crittografico a chiave pubblica con il servizio online della banca che verifica che tu e solo tu sei in possesso della Security Key, consentendo così l’accesso sicuro e il trasferimento bancario. Se le credenziali di accesso e la password vengono rubate o compromesse, si sarà comunque protetti, perché è necessaria una YubiKey fisica come 2FA. Inoltre, una volta che la YubiKey è collegata al proprio account, funge anche da sicurezza per l’aggiunta di destinatari del trasferimento al tuo account.

Questo è un importante passo avanti per gli istituti bancari e finanziari e ci congratuliamo con Bank of America per aver offerto ai propri clienti la possibilità di utilizzare un’autenticazione forte e moderna con Security Key USB per la protezione dei propri utenti. Facciamo di questo una tendenza e aumentiamo le opzioni per l’autenticazione forte! Dì ai tuoi istituti finanziari che vorresti che aggiungessero il supporto YubiKey per l’accesso all’account e la protezione dei bonifici bancari (auto Tweet).

Se sei un istituto finanziario che offre ancora soluzioni di sicurezza ai clienti finali come nome utente e password o autenticazione basata su dispositivi mobili (SMS, OTP, notifiche push), queste non sono efficaci contro l’acquisizioni di account (Account Takeover o ATO) guidate da phishing, malware, SIM swapping e attacchi man-in-the-middle (MiTM). Leggi il brief, Quattro motivi per implementare una forte autenticazione a più fattori utilizzando YubiKeys per il banking online e mobile, per scoprire come anche tu puoi guidare la differenziazione competitiva e la crescita di nuovi clienti, oppure contattaci.