Category Archives: Azure

Adaptive Network Hardening all’interno dell’Azure Security Center

Vediamo come configurare l’Adaptive Network Hardening in Azure Security Center.

Cos’è l’Adaptive Network Hardening?
Applicare i network security groups (NSG) per filtrare il traffico da e verso le risorse, migliora le vostre condizioni di sicurezza di rete. Tuttavia, esistono dei casi in cui l’attuale traffico che passa attraverso il gruppo di sicurezza NGS è un sottoinsieme di regole di sicurezza di rete definite. In questi casi, è possibile migliorare ulteriormente le condizioni di sicurezza irrigidendo le regole NSG basate sull’attuale comportamento del traffico.

La protezione avanzata di networkAdaptive Network Hardening) raccomanda di rafforzare ulteriormente le regole NSG.
Utilizza un algoritmo di machine learning che tenga conto effettivo del traffico, conosca le configurazioni fidate, la threat intelligence e altri indicatori di compromesso e poi fornisca raccomandazioni che permettano il traffico solo da specifici IP/porte.

Supponiamo, ad esempio, che la regola NSG esistente permetta il traffico da 140.20.30.10/24 alla porta 22.
Il consiglio di Adaptive Network Hardening, basato sulle analisi, sarebbe di limitare il range e permettere il traffico da 140.23.30.10/29. Quest’ultimo è infatti un range IP ristretto e non abilita il resto del traffico a quella porta.

Visualizzare alert e regole di Adaptive Network Hardening
1. All’interno del Security Center, selezionate Networking -> Adaptive Network Hardening.

Le macchine virtuali di rete sono elencate in tre tab separate:
a. Unhealthy resources – si tratta di macchine virtuali su cui attualmente sono stati innescati alert e raccomandazioni eseguendo l’algoritmo Adaptive Network Hardening.
b. Healthy resources – VM prive di alert e raccomandazioni.
c. Unscanned resources – macchine virtuali su cui non può essere eseguito l’algoritmo Adaptive Network Hardening per uno dei seguenti motivi:
Le VM sono VM classiche – sono supportate solo le Macchine Virtuali di Azure Resource Manager;
Non vi sono abbastanza dati disponibili – per poter generare raccomandazioni di potenziamento accurate, il Security Center ha bisogno di almeno 30 giorni di dati di traffico;
La VM non è protetta da un ASC standard – solo le macchine virtuali impostate su un pricing tier di tipo Security Center’s Standard sono idonee per questa funzionalità.

Adaptive Network Hardening all'interno dell'Azure Security Center

2. Dalla tab Unhealthy resources, selezionate una macchina virtuale per visualizzare alert le raccomandazioni relative alle regole di hardening da applicare.

Adaptive Network Hardening all'interno dell'Azure Security Center

Esaminare ed applicare le regole raccomandate di Adaptive Network Hardening
1. Dalla tab Unhealthy resources, selezionate una macchina virtuale. Troverete elencate regole e raccomandazioni di hardening.

Adaptive Network Hardening all'interno dell'Azure Security Center

Note: la tab Rules elenca le regole che l’Adaptive Network Hardening vi raccomanda di aggiungere. La tab Alert, invece, elenca gli alert che sono generati a causa del traffico, del flusso alle risorse che non si trova all’interno del range di IP permesso nelle regole raccomandate.

Adaptive Network Hardening all'interno dell'Azure Security Center

2. Se volete cambiare alcuni dei parametri di una regola, potete modificarli seguendo i passaggi indicati nel paragrafo Modificare una regola.
Potete anche eliminare o aggiungere una regola.

3. Selezionate la regola che volete applicare sul NSD e cliccate Enforce.

Modificare una regola
Potreste voler modificare i parametri di una regola che vi è stata raccomandata.
Per esempio, potreste modificare i range IP raccomandati.
Qui sotto elenchiamo alcune importanti linee guida per modificare una regola di Adaptive Network Hardening:
Potete modificare soltanto i parametri delle regole “allow”;
NON potete cambiare le regole “allow” e trasformarle in regole “deny”;

Note: potete creare e modificare regole di tipo “deny” direttamente dal NSG. Per maggiori dettagli vi rimandiamo al seguente articolo.

Una regola di tipo Deny all traffic è l’unico tipo di regola deny che troverete elencata e non può essere modificata. Potete invece eliminarla (indicazioni nel paragrafo Eliminare una regola).

Note: una regola di tipo deny all traffic è raccomandata quando, come risultato dell’esecuzione dell’algoritmo, il Security Center non identifica traffico che debba essere permesso, basato sulla configurazione NSG esistente. Perciò, la regola raccomandata è quella di negare tutto il traffico a quella specifica porta. Il nome di questo tipo di regola è indicata come “system generated”. Dopo aver forzato la regola, il suo nome all’interno di NSG sarà una riga costituita da un protocollo, direzione di traffico e numero casuale.

Modificare una regola di Adaptive Network Hardening:
1. Per modificare alcuni dei parametri di una regola, nella tab Rules, cliccate sui tre puntini (…) situati alla fine della riga della regola e cliccate su Edit rule.

Adaptive Network Hardening all'interno dell'Azure Security Center

2. Nella finestra Edit rule, aggiornate i dettagli che intendete modificare e cliccate Save.
3. Per applicare la regola aggiornata, dalla lista, selezionatela e cliccate Enforce.

Aggiungere una nuova regola
Potete aggiungere una regola di tipo “allow” che non vi è stata raccomandata dal Security Center.

Note: solo le regole di tipo “allow” possono essere aggiunte in questa sezione. Se volete aggiungerne una di tipo “deny”, dovete farlo direttamente sul NSG. Per maggiori dettagli: Network security group.

Aggiungere una regola di Adaptive Network Hardening:
1. Cliccate Add rule (trovate la voce in alto a sinistra).

Adaptive Network Hardening all'interno dell'Azure Security Center

2. Nella finestra Edit rule, inserite i dettagli e cliccate Save.

Note: dopo aver cliccato Save, avrete aggiunto con successo la regola e la troverete elencata assieme alle altre regole raccomandate. Non l’avete invece ancora applicata sul NSG: per farlo, dovete selezionare la regola all’interno della lista e cliccare Enforce.

3. Per applicare la nuova regola, dalla lista, selezionatela e cliccate Enforce.

Eliminare una regola
Se necessario, potete eliminare una regola raccomandata.
Ad esempio, potreste determinare che l’applicazione di una regola suggerita possa bloccare traffico legittimo.

Eliminare una regola di Adaptive Network Hardening:
1. Nella tab Rules, cliccate sui tre puntini (…) situati alla fine della regola corrispondente e cliccate su Delete rule.

Adaptive Network Hardening all'interno dell'Azure Security Center


Le informazioni presenti in questo post, sono prese dall’articolo: Adaptive Network Hardening in Azure Security Center.

Azure AD Mailbag: scoprire e bloccare l’autenticazione legacy

Molte volte ci troviamo nella situazione in cui dobbiamo aiutare i nostri clienti ad evitare attacchi alle loro password e la legacy authentication è un componente chiave dell’argomento. Questo perchè questi protocolli e client sono comunemente utilizzati per effettuare attacchi di tipo brute-force o password spray.
In questo post, andremo a vedere quali sono le sfide dell’autenticazione legacy e come utilizzare Azure AD e Microsoft Exchange Online per avere un miglior controllo dell’accesso.
Affronteremo questi argomenti con un approccio di tipo domanda e risposta.

1. Cos’è l’autenticazione legacy e quali sono i problemi che si riscontrano?
Parlando in linea generica l’autenticazione legacy si riferisce ai protocolli che utilizzano un’autenticazione base (Basic Auth).
Si tratta cioè di quei protocolli che richiedono un singolo fattore di autenticazione di username e password e tipicamente non possono applicare un secondo fattore quale componente del flusso di autenticazione.
Al lato opposto, troviamo la modern authentication (Modern Auth) che può invece richiedere un secondo fattore di autenticazione. In questo caso, solitamente l’app o il servizio in questione mostrano un frame del browser che permette all’utente di fornire quanto richiesto come secondo fattore.
Può trattarsi di un codice temporaneo, l’approvazione di una notifica push sul telefono o la risposta ad una chiamata in arrivo.

Altra differenza fondamentale è che in un percorso di autenticazione legacy, l’app client o servizio raccoglie le credenziali ed in seguito le convalida.
Essenzialmente, l’app o servizio “ottiene la fiducia” per gestire le credenziali in maniera sicura.
Nella modern authentication, le credenziali sono sempre es solo fornite ad un’autorità di fiducia (ad esempio un redirect ad Azure AD o AD Federation Services) e, dopo l’autenticazione, viene rilasciato un token per l’applicazione o un servizio che agisce per conto dell’utente.

Esempi di protocollo che usano l’autenticazione legacy sono POP3, IMAP4, e SMTP.
Ci sono altri protocolli che utilizzano Basic Auth e Modern Auth quali MAPI e EWS.

Quindi, dove sta il problema?

La single factor authentication oggigiorno non è sufficiente per rimanere al sicuro!
Le password sono deboli perchè semplici da indovinare, le persone non impiegano molto sforzo nella scelta di combinazioni più complicate e tendono a fornirle agli hacker attraverso gli attacchi (ad esempio il phishing). Una delle cose più semplici da fare per proteggerci dalle minacce alle password è implementare la multi-factor authentication (MFA).
In questo modo, anche se un aggressore dovesse impossessarsi della password di un utente, questa da sola non basterà per autenticarsi con successo ed avere accesso a dati e risorse.

I protocolli che utilizzano la legacy authentication, in particolare quelli utilizzati per recuperare email quali POP3, IMAP e EWS sono modi molto semplici per attuare attacchi di tipo brute-force e password spray perchè se una delle combinazioni di username e password tentate è corretta, l’aggressore avrà accesso alle email dell’utente.

2. Quindi cosa facciamo con questi protocolli?
La raccomandazione è di bloccare l’autenticazione legacy, o se avete dei casi particolari in azienda per cui dovete permetterne l’utilizzo, applicate alcuni controlli che ne permettano per specifici utenti e location.
Prima di farlo, cercate di capire quale sia il loro utilizzo nell’organizzazione.

Lo scorso anno, Microsoft ha fatto alcuni miglioramenti ai log di sign-in in Azure AD: ora ricevete le attività più velocemente e recuperate maggiori informazioni per ognievent.
Parte di questa informazione è la Client App property, dove venite informati sul procotollo/app utilizzati per effettuare il sign-in.

Azure AD Mailbag: scoprire e bloccare l'autenticazione legacy

La prima cosa che dovete fare è impegnare del tempo ad analizzare i log per comprendere l’utilizzo di questi client e dei protocolli in tutta l’azienda.
Per farlo, potreste scaricare i log per suddividerli ed analizzarli con Microsoft Excel o, ancora meglio, inserirli all’interno del vostro sistema di security information and event management (SIEM) che vi fornisce sicuramente funzionalità di analisi dati e alert più potenti.
Per capire come immettere i log nel SIEM, date un’occhiata a questo post: Azure AD Mailbag: Return Of The Mailbag with Azure AD Logs.
Una volta compreso chi sta usando cosa, potreste aver bisogno di aggiornare i client alle versioni che supportano la Modern Auth o convincere gli utenti a smettere di utilizzare protocolli come IMAP4 ed aggiornarsi a tecnologie più attuali.

3. Ok, siamo pronti ad imporre maggior controllo. Come facciamo?
Fino all’anno scorso, vi erano due modi di bloccare l’autenticazione legacy in Azure AD.

In ambienti federate (che utilizzano ad esempio AD FS), potreste utilizzare regole specifiche che permettano determinati protocolli e neghino l’accesso ai rimanenti.
Il tutto si complica quando dovete iniziare ad aggiungere condizioni ed eccezioni.

Implementare la MFA per utente, costringerà gli utenti ad utilizzare le password delle app per i protocolli di legacy authentication. In ogni caso, se non ne permettete l’utilizzo, bloccate
in toto questi protocolli. La cattiva notizia qui è che non potete applicare soltanto alcune condizioni: o tutte o nessuna. Inoltre, applicare la MFA per utente, non è il metodo migliore da utilizzare al giorno d’oggi: il conditional access vi dà maggiore flessibilità.
Lo scorso anno, Microsoft ha aggiunto la possibilità di bloccare l’autenticazione legacy nel conditional access e per questo vi raccomandiamo di iniziare da qui.
Con il conditional access, guadagnerete la flessibilità necessaria a supportare gli utenti o le app che hanno ancora bisogno di utilizzare i protocolli con la legacy authentication e bloccarne gli altri.

Ad esempio, se avete un’app che supporta un processo di business che utilizza l’IMAP per recuperare le email da una casella di posta di Exchange Online, potete utilizzare il conditional access per permettere quel flow soltanto per quello specifico utente se la sorgente IP è uno dei vostri IP e bloccare qualsiasi altro tentativo.
Vi rimandiamo all’articolo Block legacy authentication to Azure AD with conditional access per saperne di più.

Azure AD Mailbag: scoprire e bloccare l'autenticazione legacy

Quello che ha creato un po’ di confusione è stato che le policy di conditional access non includono la legacy authentication dei client di default.
Questo significa che se avete una policy di conditional access che applica l’MFA per tutti gli utenti e le app cloud, non verrà bloccata l’autenticazione legacy dei client (o di “Other clients” considerato che la CA UI si riferisce a quelli). La legacy authentication dei client può ancora operare l’autenticazione soltanto con username e password. Per bloccare, create semplicemente una nuova policy.

Un altro modo per bloccare l’autenticazione legacy è impedendola dal lato service-side o resource-side (vs piattaforma di autentificazione).
Raccomandiamo quest’approccio se combinato con le policy di Azure AD Conditional Access. Ad esempio, in MS Exchange Online, potete disabilitare il POP3 o l’IMAP per l’utente. Il problema di questa disabilitazione è che non volete bloccare i protocolli che possono effettuare sia la legacy che la modern authentication (come EWS, MAPI) perchè vi servono.
Per risolvere l’inghippo, Exchange Online ha rilasciato una nuova funzionalità chiamata authentication policies che può essere utilizzata per bloccare le autenticazioni legacy per protocollo dello specifico utente o per l’intera organizzazione.
Ci piace questa caratteristica perchè, con questo approccio, state bloccando i tentativi di utilizzo del protocollo a monte, il che significa che gli aggressori non tenteranno nemmeno di indovinare le password. La connessione al protocollo è negata ancor prima del controllo delle credenziali su Azure AD o gli AD Federation Services quindi l’esecuzione viene fatta pre-autenticazione.
Le policy di conditional access sono invece valutate dopo che l’utente (o l’aggressore) ha effettuato l’autenticazione quindi l’enforcement è eseguito post-autenticazione.

Per maggiori informazioni: Disable Basic authentication in Exchange Online.


Le informazioni presenti in questo post, sono prese dall’articolo: Azure AD Mailbag: Discovering and blocking legacy authentication.

Supporto di AzCopy su Azure Storage Explorer disponibile in public preview

Siamo felici di annunciarvi la public preview di AzCopy all’interno di Azure Storage Explorer.
AzCopy è un’utility della riga di comando che vi permette di effettuare performanti trasferimenti di dati da e per account storage.
La nuova versione migliora ulteriormente performance ed affidabilità attraverso un design scalabile. Con AzCopy è possibile copiare dati tra un file system e un account di archiviazione o tra più account di archiviazione.

Azure Storage Explorer fornisce un’interfaccia utente per diverse attività di storage ed ora supporta l’utilizzo di AzCopy quale motore di trasferimento per fornire il più elevato standard per il trasferimento dei vostri file su Azure Storage. La funzionalità è ora disponibile in versione preview all’interno di Azure Storage Explorer.

Abilitare AzCopy per upload e download BLOB
Molti utenti hanno sottolineato l’importanza delle performance circa il trasferimento dati.
Siamo onesti, abbiamo tutti di meglio da fare che aspettare che i file vengano trasferiti su Azure. Ora, con AzCopy in Azure Storage Explorer, risparmierete un bel po’ di seccature.

Con AzCopy in preview, infatti, le operazioni blob saranno molto più veloci che in precedenza.
Per abilitare quest’opzione, recatevi sul menù Preview e selezionate la voce Use AzCopy for improved blob Upload and Download.

Microsoft è al lavoro sul supporto per i file Azure e raggruppare le eliminazioni dei blob.
Rilasciate i vostri feedback e le vostre opinioni nel GitHub repository.

Supporto di AzCopy su Azure Storage Explorer disponibile in public preview

Quanto è veloce?
Con un breve test nel vostro ambiente, sarete in grado di vedere significativi miglioramenti nel caricamento dei file con AzCopy in Azure Storage Explorer.
Tenete presente che i tempi possono variare da macchina a macchina.

Storage Explorer Storage Explorer w/AzCopyV10 Improvement
10K 100KB files 1 hour 36 minutes 59 seconds 98.9 percent
100 100MB 5 minutes 12 seconds 1 minute 35 seconds 69.5 percent
1 10GB file 3 minutes 41 seconds 1 minute 40 seconds 54.7 percent

Supporto di AzCopy su Azure Storage Explorer disponibile in public preview
Nell’immagine qui sopra vediamo AzCopy in azione con updload/download di file blob 1 x 10GB file

Supporto di AzCopy su Azure Storage Explorer disponibile in public preview
In quest’altra immagine, invece AzCopy in azione con uploads/downloads di file blob 10,000 x 10KB

Prossimi step
Vi invitiamo a provare la funzionalità di AzCopy in preview e a rilasciare i vostri feedback.
Se riscontrate qualche problema o volete dare un suggerimento circa nuove features, utilizzate il canale GitHub repository.


Le informazioni presenti in questo post sono tratte dal seguente articolo: AzCopy support in Azure Storage Explorer now available in public preview.

Microsoft Azure Sentinel: sistema intelligente di security analytics per la tua azienda

Microsoft Azure Sentinel: sistema intelligente di security analytics per la tua azienda

Gestire la sicurezza può diventare un processo infinito ed estenuante: tra i crescenti attacchi sempre più sofisticati, e alert con tempi di risoluzione a lungo termine, gli attuali strumenti di Security Information and Event Management (SIEM) non riescono a tenere il passo.

I team di Security Operations (SecOps) sono letteralmente travolti da un alto numero di segnalazioni ed impiegano moltissimo tempo a risolvere attività quali il set up di infrastrutture e la maintenance. Il risultato di tutto questo lavoro però, è che molte minacce passano comunque in sordina. Inoltre, un deficit di 3.5 milioni di professionisti della security a partire dal 2021 accrescerà ulteriormente le sfide per i team di security operations (articolo: Cybersecurity Jobs Report 2018-2021).
In uno scenario di questo tipo, è chiaro che la tua azienda ha bisogno di una soluzione che supporti il tuo attuale team SecOps in modo da avere una panoramica più chiara delle minacce ed eliminare le disattenzioni.
Per questo motivo, Microsoft ha re-inventato lo strumento di SIEM con una soluzione cloud nativa chiamata Microsoft Azure Sentinel.
Microsoft Azure Sentinel fornisce sistemi di analytics intelligenti e scalabili sul cloud per l’intera azienda. Come afferma il suo nome, è una vera e propria sentinella a difesa dell’azienda che tiene d’occhio l’organizzazione per individuare e bloccare le minacce prima che queste possano causare danni.
Persegue questo obiettivo semplificando la raccolta dei dati relativi all’intera organizzazione, sia essa on premise, cloud o ibrida. I dati vengono raccolti da diverse fonti, quali dispositivi, utenti, app, server e cloud.
Utilizza il potere dell’intelligenza artificiale a supporto dell’identificazione rapida delle minacce e ti libera dagli oneri dei tradizionali SIEM eliminando la necessità di impiegare il tuo tempo nell’impostazione, maintenance e scalabilità dell’infrastruttura. Poiché è costruita su Azure, offre flessibilità e velocità pressoché illimitate, oltre alla scalabilità automatica necessaria per soddisfare ogni esigenza a livello di sicurezza riducendo al tempo stesso i costi per l’IT.

I sistemi SIEM tradizionali risultano spesso costosi da acquistare e mettere in funzione: richiedono di frequente un impegno upfront e alti costi per la maintenance dell’infrastruttura e l’inserimento dei dati. Con Azure Sentinel non vi sono costi iniziali, pagate solo per quello che utilizzate.
Molte organizzazioni stanno utilizzando Office 365 e adottano sempre di più sistemi di sicurezza avanzata e compliance incluse in Microsoft 365. A livello di security, potreste voler combinare dati di sicurezza prevenienti dagli utenti ad applicazioni end point ad informazioni provenienti dalla vostra infrastruttura a dati di terze parti con il fine di comprendere un attacco completo. L’ideale sarebbe che possiate farlo all’interno di confini di compliance di un singolo cloud provider.
Oggi vi annunciamo la possibilità di portare i dati di attività di Office 365 su Azure Sentinel gratuitamente. Ci vogliono solo pochi click per memorizzare i dati all’interno del cloud di Microsoft.

“Con Microsoft Azure Sentinel, possiamo rispondere al meglio alle principali sfide SIEM dei nostri clienti, mentre semplifichiamo il data residency e le preoccupazioni da GDPR”.
Andrew Winkelmann, Global Security Consulting Practice Lead, Accenture

Microsoft Azure Sentinel: sistema intelligente di security analytics per la tua azienda

Vediamo ora come Azure Sentinel vi aiuta a fornire operazioni di sicurezza cloud native.

Raccogli i dati di tutta l’azienda in maniera semplice
Con Azure Sentinel potete raccogliere tutti i dati relativi alla sicurezza grazie a connettori incorporati, integrazioni native di segnali Microsoft e supporto per i formati di log industry standard quali formati common event e syslog. In pochi click, potete importare i vostri dati di Microsoft Office 365 gratuitamente e combinarli con altri dati di sicurezza per analizzarli.
Azure Sentinel utilizza Azure Monitor che è costruito su un database di log analytics verificato e scalabile che incorpora più di 10 petabyte al giorno e fornisce un veloce motore di ricerca che processa milioni di record in pochi secondi.

Microsoft è in stretta collaborazione con molti partner all’interno della Microsoft Intelligent Security Association.
Azure Sentinels si connette a famose soluzioni tra cui Palo Alto Networks, F5, Symantec, Fortinet e Check Point (molte altre sono in arrivo).
Azure Sentiles si integra inoltre con Microsoft Graph Security API, il che vi permette di importare i vostri propri threat intelligence feeds e customizzare il rilevamento delle minacce e le regole relative agli alert.
Ci sono dashboard personalizzabili che vi danno una visione ottimizzata a seconda dei vostri specifici use case.

Adam Geller, Senior Vice President, SaaS, virtualization, e cloud-delivered security of Palo Alto Networks ha dichiarato:
“Siamo soddisfatti della nostra continua collaborazione con Microsoft e del lavoro che stiamo facendo per fornire una migliora strumentazione di sicurezza per i nostri clienti congiunti. Quest’ultima integrazione, poi, permette ai clienti di trasmettere i log dei loro firewall virtualizzati ad Azure Sentinel, di utilizzare dashboard custom e l’intelligenza artificiale per scoprire potenziali problemi di sicurezza.
I clienti di Palo Alto Networks possono inoltre estendere Autofocus e altri strumenti di threat intelligence di terze parti ad Azure Sentinels attraverso la nuova integrazione tra MineMeld ed il Microsoft Graph Security API.”

Analizza le minacce sfruttando l’AI
I security analysts affrontano un carico ingente di lavoro dalla selezione al filtro di moltissimi alert alla correlazione degli stessi sia essa manuale o automatica con un tradizionale sistema di correlazione.
Per questo Azure Sentinel utilizza algoritmi di machine learning per mettere in relazione milioni di anomalie a bassa fedeltà per presentare incidenti di sicurezza a massima fedeltà agli analisti. Le tecnologie di ML vi aiuteranno ad ottenere velocemente valori e risultati provenienti da un significativo ammontare di dati di sicurezza.
Per esempio, potete velocemente individuare un account compromesso utilizzato per distribuire un ransomware in un’applicazione cloud.
Questo vi aiuta a ridurre drasticamente i fastidi: è stata infatti osservata una riduzione complessiva che arriva fino al 90% di alert durante la valutazione.

Reed M. Wiedower, CTO di New Signature ha dichiarato: “Riconosciamo un enorme valore ad Azure Sentinel per la sua capacità di generare risultati attorno ad un vasto raggio di diversi componenti dell’infrastruttura”

Questi modelli di machine learning integrati sono basati sulla longeva esperienza del Microsoft security team nella difesa dei cloud asset dei clienti.
Non devi per forza essere un data scientist per poter sfruttare i benefici forniti da Azure Sentinels. Se invece lo sei e vvuoi customizzare ed arricchire il rilevamento, puoi importare i tuoi modelli su Azure Sentinel utilizzando il servizio integrato di Azure Machine Learning.
Inoltre, Azure Sentinel, si può connettere ai dati dei prodotti di security di Microsoft 365 relativi all’attività dell’utente: questi possono poi essere combinati con altre sorgenti dati per fornire visibilità ad un’intera sequenza di attacchi.

Rileva attività sospette
L’indagine grafica e basata sull’AI ridurrà il tempo necessario a comprendere la piena portata di un attacco ed il suo impatto.
Potete visualizzare l’attacco ed intraprendere azioni veloci dalla stessa dashboard.

Microsoft Azure Sentinel: sistema intelligente di security analytics per la tua azienda

La ricerca proattiva di attività sospette è un altro compito critico per i security analysts.
Spesso, il processo attraverso cui i SecOps raccolgono ed analizzano i dati è un’operazione ripetitiva che può essere automatizzata.
Oggi, Azure Sentinel fornisce due funzionalità che vi permettono di automatizzare le vostre analisi costruendo motori di individuazione ed Azure Notebooks basati su Jupyter notebooks. Microsoft ha sviluppato una serie di query e Azure Notebooks basati sulla ricerca proattiva che eseguono i team di Microsoft’s Incident Response e Threat Analysts.
Con l’evoluzione del panorama delle minacce, evolvono anche le query di Microsoft e Azure Notebooks che continueranno a distribuirne di nuove attraverso la Azure Sentinel GitHub community.

Automatizzare le attività comuni e le risposte alle minacce
Abbiamo visto come l’intelligenza artificiale perfezioni la capacità di individuare i problemi. Una volta risolta la problematica, però, sarebbe bello non doversi trovare a risolvere continuamente lo stesso problema ma, piuttosto, automatizzare la risoluzione. Azure Sentinel fornisce automazione integrata e la strumentazione con playbook predefiniti o customizzati per risolvere le attività ripetitive e reagire velocemente alle minacce.
Azure Sentinel aumenterà le difese enterprise esistenti e gli strumenti di investigazione, inclusi i migliori prodotti di sicurezza, gli strumenti sviluppati internamente e altri sistemi quali le applicazioni di HR management e di workflow management quali ServiceNow.

Microsoft Azure Sentinel: sistema intelligente di security analytics per la tua azienda

La threat intelligence di Microsoft è senza eguali poichè è arricchita dall’analisi di più di 6.5 trilioni di segnali quotidiani e da anni di expertise sulla sicurezza e scalabilità del cloud che ti permetterà di ammodernare le tue security operations.

“Azure Sentinel fornisce una SIEM proattiva e cloud nativa che aiuterà i clienti a semplificare le loro security operations e a scalare all’aumentare delle dimensioni”.
Richard Diver, Cloud Security Architect, Insight Enterprises

Metti un fine ai processi di sicurezza infiniti.
Sfrutta la potenza del cloud e l’intelligenza su larga scala. Rendi i tuoi sistemi di threat protection più intelligenti e veloci grazie all’AI.
Importa i dati di Microsoft Office 365 per effettuarvici gratuitamente attività di security analytics.
Microsoft Azure Sentinels è disponibile oggi in preview gratuita all’interno del Portale di Azure.

Connessione di Azure Active Directory con molteplici foreste: “the specified domain does not exist or cannot be contacted”

Configurare una soluzione di sincronizzazione multi foresta per un unico tenant di Office 365, è un’operazione abbastanza semplice ma vi sono alcuni trucchetti da tenere presenti:

1. La risoluzione del DNS è critica, aggiungendo alcune voci del file host non risolverete nulla. Utilizzate un forwarder condizionale ad un DC per ogni foresta;
2. Assicuratevi che le porte firewall appropriate siano aperte.
Maggiori info qui: Porte e protocolli necessari;
3. MOLTO IMPORTANTE Assicuratevi di scrivere il vostro login nel formato NetBIOS ed includete il suffisso. Ad esempio, LIEBEN.NU\Admin, se utilizzate LIEBEN\Admin non funzionerà.

Vi raccomandiamo di seguire alla lettera questi punti fondamentali.
Nel caso in cui non lo facciate, probabilmente, vi si presenterà il seguente errore.

[ERROR] Caught exception while validating the domain credentials and retrieving domain FQDN of the specified user XXXX.XXX\Admin.
Exception Data (Raw): System.DirectoryServices.ActiveDirectory.ActiveDirectoryObjectNotFoundException: The specified domain does not exist or cannot be contacted.
at System.DirectoryServices.ActiveDirectory.Domain.GetDomain(DirectoryContext context)
at Microsoft.Online.Deployment.Framework.Providers.ActiveDirectoryProvider.ValidateUserCredentials(String domainName, String username, SecureString password, String& domainFqdn)
at Microsoft.Online.Deployment.OneADWizard.UI.WizardPages.ConfigSyncDirectoriesPageViewModel.ValidateADDirectoryConnection(DirectoryConnectionViewModel connection)