Immagina questo: il tuo team di sicurezza ha trascorso gli ultimi sei mesi a rafforzare il tuo ambiente di produzione primario. Hai applicato patch ai server, bloccato le API e eseguito un Penetration Test manuale che ha dato esito positivo. Ti senti bene. Vai a dormire pensando che il perimetro sia sicuro.
Nel frattempo, in un angolo diverso dell'azienda, un responsabile marketing ha deciso di aver bisogno di una landing page rapida per una campagna stagionale. Non voleva aspettare due settimane affinché un ticket Jira venisse elaborato dall'IT, quindi ha utilizzato una carta di credito aziendale per avviare una piccola istanza AWS. Per far funzionare la pagina, ha caricato una vecchia versione di WordPress e ha lasciato attive le credenziali di amministratore predefinite. Ha anche accidentalmente lasciato aperto un bucket S3 contenente un elenco di e-mail dei clienti perché il "tutorial" che ha seguito online gli ha detto di impostare le autorizzazioni su "pubblico".
Quella landing page è ora una porta spalancata. Un aggressore non ha bisogno di sfondare il tuo muro di produzione rafforzato; deve solo trovare la porta laterale trascurata che il tuo team IT non sa nemmeno che esista.
Questa è la realtà dello Shadow IT. Di solito non nasce dalla cattiveria; nasce dal desiderio di essere produttivi. Ma dal punto di vista della sicurezza, è un incubo. Non puoi proteggere ciò che non conosci. Questo è il motivo per cui la mappatura automatizzata della superficie di attacco è passata dall'essere un "nice-to-have" a un requisito fondamentale per qualsiasi azienda che operi nel cloud.
Cos'è esattamente lo Shadow IT e perché è così pericoloso?
Lo Shadow IT si riferisce a qualsiasi software, hardware o servizio cloud utilizzato dai dipendenti all'interno di un'organizzazione senza l'approvazione esplicita o la conoscenza del dipartimento IT o di sicurezza. Ai vecchi tempi, questo significava che qualcuno portava il proprio router wireless in ufficio. Oggi è molto più insidioso. È uno strumento SaaS per la gestione dei progetti, un'app Heroku non autorizzata o un ambiente di test "temporaneo" che è stato dimenticato ma mai eliminato.
La psicologia del "Workaround"
La maggior parte dei dipendenti non sta cercando di aggirare la sicurezza. Stanno solo cercando di fare il proprio lavoro. Quando il processo ufficiale per ottenere l'approvazione di uno strumento richiede tre settimane e un pulsante "Free Trial" richiede tre secondi, vince il percorso di minor resistenza. Questo crea una cultura di infrastruttura nascosta.
Il divario di sicurezza
Il pericolo dello Shadow IT non è solo la mancanza di una politica delle password. È la completa mancanza di visibilità. Quando le risorse sono nascoste, perdono:
- Patch Management: un server non gestito non verrà aggiornato quando viene annunciata una vulnerabilità Zero Day critica.
- Identity and Access Management (IAM): questi strumenti spesso non si integrano con Single Sign-On (SSO), il che significa che quando un dipendente lascia l'azienda, ha ancora accesso a quello strumento SaaS non autorizzato.
- Compliance Monitoring: se sei soggetto a SOC 2 o HIPAA, devi dimostrare dove risiedono i tuoi dati. Se i dati si trovano in un bucket cloud non approvato, sei tecnicamente non conforme.
Come lo Shadow IT diventa un punto di ingresso
Gli aggressori usano la "ricognizione" come primo passo. Non iniziano attaccando la tua pagina di accesso principale. Utilizzano strumenti come Shodan, Censys o semplici Google Dorks per trovare risorse associate al tuo dominio o intervallo IP. Cercano le cose "dimenticate": dev-test.yourcompany.com o marketing-promo-2023.yourcompany.cloud. Una volta trovato un punto debole, come un plugin obsoleto su un sito non autorizzato, ottengono un punto d'appoggio. Da lì, si muovono lateralmente attraverso la tua rete fino a raggiungere i gioielli della corona.
Il passaggio verso la mappatura automatizzata della superficie di attacco
Per molto tempo, la soluzione a questo era un inventario manuale. Una volta all'anno, il responsabile IT inviava un foglio di calcolo chiedendo: "Quali strumenti stai utilizzando?". Il problema è che le persone mentono, le persone dimenticano e, quando il foglio di calcolo viene restituito, sono state distribuite altre tre app non autorizzate.
La mappatura automatizzata della superficie di attacco cambia il gioco. Invece di chiedere ai dipendenti cosa stanno utilizzando, utilizzi strumenti che esaminano la tua organizzazione dall'esterno verso l'interno, esattamente come farebbe un aggressore.
Cos'è la mappatura della superficie di attacco?
Nella sua essenza, la mappatura della superficie di attacco è il processo di scoperta di ogni risorsa esposta a Internet associata alla tua organizzazione. Questo include:
- Nomi di dominio e sottodomini: trovare quegli ambienti
test,devostagingnascosti. - Indirizzi IP: identificare le istanze cloud che potrebbero non avere un record DNS.
- Porte e servizi aperti: sapere che la porta 22 (SSH) o la porta 3389 (RDP) è accidentalmente esposta al mondo.
- API endpoints: trovare "Zombie APIs" non documentate che sono state utilizzate per una vecchia versione della tua app.
- Bucket di archiviazione cloud: individuare S3 o Azure Blob storage mal configurati.
Perché "Automatizzato" è la parola chiave
L'ambiente cloud moderno è liquido. Gli sviluppatori avviano e smantellano container e istanze in pochi minuti. Una mappa manuale è obsoleta nel momento in cui è terminata. L'automazione consente la scoperta continua.
È qui che si inserisce una piattaforma come Penetrify. Invece di un audit statico, ottieni un flusso continuo di visibilità. Funziona essenzialmente come un esploratore persistente, scansionando il tuo perimetro per garantire che se uno sviluppatore avvia un'istanza non autorizzata oggi, venga contrassegnata e catalogata domani, piuttosto che essere scoperta da un hacker il mese prossimo.
L'anatomia di un processo di mappatura efficace
Se stai cercando di implementare la mappatura della superficie di attacco, non puoi semplicemente eseguire una singola scansione e considerarla conclusa. Deve essere un processo strutturato che si sposta dalla scoperta ampia all'analisi approfondita.
Fase 1: Scoperta delle risorse (la "rete ampia")
Il primo passo è trovare tutto. Ciò comporta diverse tecniche:
- Ricerca WHOIS: Verifica dei domini registrati e dei record di proprietà.
- Enumerazione DNS: Utilizzo di tecniche come il "brute-forcing" dei sottodomini o l'analisi dei record DNS (CNAME, MX, TXT) per trovare host nascosti.
- Log di Trasparenza dei Certificati (CT): Ogni volta che viene emesso un certificato SSL/TLS per un dominio, viene registrato pubblicamente. Questo è uno dei modi più efficaci per trovare sottodomini che non sono collegati da nessuna parte sul tuo sito web principale.
- Scansione degli Intervalli IP: Scansione dei blocchi IP assegnati alla tua azienda per trovare host attivi che potrebbero non avere un nome DNS.
Fase 2: Identificazione del Servizio (Il "Cos'è?")
Una volta che hai un elenco di IP e domini, devi sapere cosa è in esecuzione su di essi. Un elenco di indirizzi IP è inutile a meno che tu non sappia che 1.2.3.4 sta eseguendo una vecchia versione di Apache sulla porta 80 e un database MongoDB esposto sulla porta 27017.
Questo comporta il "banner grabbing" e il fingerprinting del servizio. Il sistema invia una richiesta alla porta e analizza la risposta per determinare il software e la versione.
Fase 3: Analisi delle Vulnerabilità (Il "È rotto?")
Ora che sai cosa hai, controlli le debolezze note. È qui che entra in gioco la scansione automatizzata. Il sistema controlla le versioni rilevate rispetto ai database di vulnerabilità note (CVE).
- Quel sito WordPress sta eseguendo la versione 4.2? (Rischio critico).
- Il server SSH consente l'autenticazione tramite password? (Rischio elevato).
- C'è un file
.envaccessibile pubblicamente? (Rischio catastrofico).
Fase 4: Prioritizzazione e Remediation (Il "Correggilo")
Il problema più grande con gli strumenti automatizzati è la "alert fatigue". Se uno strumento ti fornisce 5.000 avvisi di gravità "Bassa", li ignorerai tutti, incluso l'unico avviso "Critico" nascosto nel mezzo.
Una mappatura efficace richiede un modo per classificare il rischio in base a:
- Esposizione: È aperto a tutto il mondo o solo a un intervallo IP specifico?
- Impatto: Questo server ha accesso al database di produzione o è solo un sito statico di brochure?
- Facilità di Sfruttamento: Esiste uno script di exploit pubblico disponibile per questa vulnerabilità?
Mappatura del Cloud "Nascosto": AWS, Azure e GCP
Il cloud computing ha reso lo Shadow IT esponenzialmente più facile. In passato, ottenere un server richiedeva un rack fisico e un cavo. Ora, è un clic di un pulsante. Ma gli ambienti cloud-native introducono tipi specifici di rischi che gli scanner di rete tradizionali spesso non rilevano.
Il Pericolo delle Istanze "Orfane"
In molte aziende, uno sviluppatore potrebbe creare un "Proof of Concept" (PoC) in un account sandbox per testare una nuova funzionalità. Usano una carta di credito aziendale per evitare la burocrazia interna. Una volta terminato il PoC, lo sviluppatore passa a un progetto diverso, ma si dimentica di terminare l'istanza.
Queste istanze orfane sono miniere d'oro per gli hacker. Raramente vengono patchate, spesso hanno ruoli IAM eccessivamente permissivi e vengono completamente ignorate dal team di sicurezza centrale.
Storage Cloud Mal Configurato
Abbiamo visto innumerevoli titoli su "bucket S3 trapelati". Questo accade perché lo storage cloud è progettato per essere flessibile. Un clic sbagliato nel pannello delle autorizzazioni può cambiare un bucket da "Privato" a "Pubblico".
La mappatura automatizzata della superficie di attacco cerca specificamente questi modelli. Non cerca solo porte aperte; interroga le API cloud per vedere se i bucket di storage associati ai nomi della tua azienda sono accessibili senza autenticazione.
Proliferazione di API e API Zombie
Le app moderne sono essenzialmente una raccolta di API. Man mano che le aziende si evolvono, rilasciano v1, v2 e v3 della loro API. Spesso, v1 viene lasciata in esecuzione per supportare alcuni vecchi client, ma manca delle patch di sicurezza e dei controlli di autenticazione di v3.
Questa è chiamata "API Zombie". Poiché non è collegata nella documentazione corrente, è invisibile agli sviluppatori, ma non a un attaccante che sta scansionando /api/v1/users.
Confronto: Penetration Testing Manuale vs. Mappatura Automatizzata
Un malinteso comune è che un Penetration Test annuale sostituisca la necessità di una mappatura automatizzata della superficie di attacco. In realtà, sono due strumenti diversi per due lavori diversi.
| Funzionalità | Penetration Testing Manuale | Mappatura Automatizzata della Superficie di Attacco |
|---|---|---|
| Frequenza | Una o due volte all'anno | Continua / Quotidiana |
| Ambito | Analisi approfondita di un target specifico | Ampia visione di tutto |
| Obiettivo | Trovare difetti logici complessi e concatenare exploit | Trovare "low hanging fruit" e asset nascosti |
| Costo | Alto (Tariffe di società specializzate) | Prevedibile (Modello SaaS) |
| Risultato | Un report dettagliato (istantanea nel tempo) | Una dashboard dinamica del tuo perimetro |
| Rilevamento | Trova cose che un umano può dedurre | Trova cose che una macchina può scansionare |
Pensa al Penetration Testing manuale come a un'immersione in acque profonde. Vai in profondità in un'area specifica per trovare i tesori nascosti (o i difetti). La mappatura automatizzata è come un satellite in alto. Ti mostra dove sono le isole, dove si stanno spostando le coste e se un nuovo vulcano è appena eruttato sul tuo perimetro.
Se fai l'immersione in acque profonde solo una volta all'anno, ti perderai il fatto che una nuova "isola" (asset Shadow IT) è apparsa tre mesi dopo il tuo test.
Passo dopo Passo: Come Iniziare a Ridurre il Rischio Shadow IT
Non è necessario assumere un team di sicurezza di 20 persone per tenere la situazione sotto controllo. Puoi iniziare con alcuni passaggi pratici.
Passaggio 1: Stabilire un inventario "Known-Good"
Prima di poter trovare l'IT "Shadow", devi sapere cos'è l'IT "Light". Collabora con i tuoi team DevOps e IT per creare un elenco di:
- Tutti i domini e sottodomini ufficiali.
- Tutti gli account cloud approvati (AWS/Azure/GCP).
- Un elenco di strumenti SaaS di terze parti approvati.
Passaggio 2: Implementare uno strumento di discovery esterno
Invece di controllare manualmente i log, inizia a utilizzare uno strumento che esegue la discovery continua. Ti serve qualcosa che si integri con il tuo dominio e inizi a mappare.
Se stai usando Penetrify, questo avviene automaticamente. La piattaforma inizia identificando la tua impronta digitale, trovando i sottodomini che hai dimenticato e mappando i servizi in esecuzione su di essi.
Passaggio 3: L'"Audit di Discovery"
Una volta completata la prima scansione, probabilmente troverai un elenco di asset di cui non conoscevi l'esistenza. Ora arriva la parte umana. Per ogni asset sconosciuto, chiediti:
- Chi è il proprietario? (Verifica la proprietà tramite record DNS o e-mail interne).
- Qual è il suo scopo? (È un vecchio sito di marketing? Un laboratorio di test di un dev?).
- È ancora necessario? (Se è un progetto del 2019, eliminalo).
- È protetto? (Ha una password? È patchato?).
Passaggio 4: Implementare un processo di provisioning "Security-First"
Per impedire il ritorno dello Shadow IT, devi risolvere il motivo per cui si verifica. Se il processo per ottenere un nuovo strumento è troppo lento, le persone lo aggireranno.
- Crea una "Fast Track" per strumenti a basso rischio.
- Fornisci un "Service Catalog" di strumenti pre-approvati.
- Informa il personale sul perché lo Shadow IT è un rischio. Non limitarti a dire "è contro le regole"; spiega che una landing page non autorizzata potrebbe portare a una violazione dei dati a livello aziendale.
Errori comuni nella gestione delle superfici di attacco
Anche le aziende con i migliori strumenti commettono errori. Ecco alcune cose da evitare.
1. Eccessiva dipendenza dagli scanner interni
Molte aziende eseguono vulnerability scanner all'interno della loro rete. Questo è ottimo per trovare server interni non patchati, ma è inutile per trovare Shadow IT. Uno scanner all'interno della tua rete vede solo ciò che è già connesso alla tua rete. Non troverà quell'istanza AWS non autorizzata che un marketer ha configurato utilizzando un account personale. Devi eseguire la scansione dall'esterno verso l'interno.
2. Ignorare gli avvisi di gravità "Low"
È allettante ignorare un avviso "Low" o "Medium", come un banner del server obsoleto. Tuttavia, gli aggressori spesso "concatenano" le vulnerabilità. Una vulnerabilità "Low" (information disclosure) fornisce loro il numero di versione, che consente loro di trovare una vulnerabilità "Medium" (un vecchio plugin), che infine consente loro di eseguire una vulnerabilità "High" (Remote Code Execution). Se elimini le cose "Low", rompi la catena.
3. Dimenticare i record DNS
Molti team dimenticano di monitorare i propri record DNS. I vecchi record CNAME che puntano a servizi cloud dismessi possono portare al "Subdomain Takeover". Questo è quando un aggressore rivendica la risorsa cloud abbandonata e di fatto assume il controllo del tuo sottodominio, consentendogli di rubare i cookie o lanciare attacchi di phishing da un dominio attendibile.
4. Trattare la mappatura come un'attività "una volta al trimestre"
Come accennato in precedenza, il cloud cambia di minuto in minuto. Se mappi la tua superficie solo ogni tre mesi, hai una finestra di 90 giorni in cui una nuova vulnerabilità può essere sfruttata prima ancora di sapere che l'asset esiste.
Esempio pratico: il percorso di una startup SaaS
Diamo un'occhiata a uno scenario ipotetico. "CloudScale AI" è una società SaaS B2B in rapida crescita. Hanno un ottimo prodotto e un team snello.
La configurazione: Hanno un ambiente di produzione principale su AWS. Usano Terraform per l'infrastructure as code e hanno una pipeline CI/CD. Sulla carta, sono molto sicuri.
Il divario: Durante una fase di crescita, il team di vendita voleva un "ambiente demo personalizzato" per un grande cliente enterprise. Non volevano aspettare che il responsabile DevOps costruisse una nuova VPC, quindi hanno utilizzato un account AWS separato e non gestito per avviare un mirror dell'app. Per rendere "facile" per il cliente, hanno disabilitato alcuni dei requisiti MFA più severi e hanno lasciato aperta una porta di debug.
La discovery:
CloudScale AI ha integrato Penetrify per gestire la propria postura di sicurezza continua. Entro 24 ore, Penetrify ha segnalato un nuovo sottodominio: demo-client-x.cloudscale.ai.
Il team di sicurezza era confuso: non avevano autorizzato alcun nuovo sottodominio. Dopo un'indagine, hanno scoperto che la porta di debug era aperta (Port 8080) e che la versione dell'app in esecuzione lì era due versioni indietro rispetto alla produzione.
La risoluzione: Poiché la discovery era automatizzata, il team ha trovato la perdita in un giorno. Senza di essa, l'ambiente demo sarebbe rimasto aperto fino all'"audit annuale" sei mesi dopo. Il team ha eliminato l'account non autorizzato, ha migrato la demo all'infrastruttura ufficiale e ha implementato una nuova politica per le demo dei clienti.
Gestire le OWASP Top 10 nel contesto delle superfici di attacco
Quando stai mappando la tua superficie di attacco, stai essenzialmente cercando le "porte" che portano alle vulnerabilità OWASP Top 10. Ecco come la mappatura della superficie di attacco aiuta a mitigare alcuni dei rischi più comuni.
Broken Access Control
Se trovi un API endpoint non documentato (/api/test/getUsers), c'è un'alta probabilità che manchi dei controlli di accesso appropriati che si trovano nell'API di produzione. Mappando questi endpoint, puoi applicare la stessa logica di autenticazione alle parti "nascoste" della tua app.
Cryptographic Failures
La mappatura automatizzata identifica i certificati in tutti i tuoi sottodomini. Può segnalare i certificati scaduti, che utilizzano una crittografia debole (come TLS 1.0) o che sono auto-firmati. Ciò garantisce che i dati in transito siano crittografati su tutta la superficie, non solo sul sito principale.
Componenti Vulnerabili e Obsoleti
Questo è il vantaggio principale della mappatura automatizzata. Acquisendo le impronte digitali delle versioni del software su ogni asset scoperto, puoi vedere immediatamente dove stai eseguendo una vecchia versione di Nginx, un framework Java obsoleto o una versione legacy di PHP.
Errori di Configurazione di Sicurezza
Un bucket S3 aperto, una password predefinita "admin/admin" su un router o un elenco di directory abilitato su un server web: questi sono tutti errori di configurazione di sicurezza. Gli strumenti di mappatura identificano questi "low hanging fruits" prima che lo faccia lo script di un attaccante.
Una Checklist per la Gestione della Tua Superficie di Attacco
Se stai eseguendo un audit della tua configurazione oggi, utilizza questa checklist:
- Audit del Dominio Esterno: Abbiamo un elenco di tutti i domini che possediamo?
- Rilevamento dei Sottodomini: Abbiamo controllato i log CT per i sottodomini di cui non siamo a conoscenza?
- Inventario degli Account Cloud: Possiamo rendere conto di ogni account AWS/Azure/GCP collegato a un'e-mail aziendale o a una carta di credito?
- Audit delle Porte: Ci sono porte aperte (SSH, RDP, Database) che dovrebbero essere dietro una VPN?
- Inventario delle API: Esiste un elenco di tutti gli endpoint API attivi, comprese le versioni legacy?
- Controllo dei Certificati: Tutti gli asset rivolti a Internet utilizzano certificati TLS validi e moderni?
- Revisione degli Asset Orfani: Abbiamo un processo per la dismissione degli asset quando un progetto termina?
- Monitoraggio Continuo: Stiamo scansionando il nostro perimetro quotidianamente/settimanalmente o solo una volta all'anno?
Il Ruolo del "Penetration Testing as a Service" (PTaaS)
Il modello tradizionale di "assumi un'azienda, ottieni un report PDF" sta morendo. È troppo lento per il cloud. Il settore si sta muovendo verso il PTaaS (Penetration Testing as a Service), che è esattamente ciò che Penetrify fornisce.
Il PTaaS combina il meglio di entrambi i mondi: l'intelligenza della logica del Penetration Testing e la velocità dell'automazione del cloud. Invece di un report statico, ottieni una dashboard. Invece di un evento annuale, ottieni un servizio continuo.
Per le PMI e le startup SaaS, questo è l'unico modo per mantenere la sicurezza senza assumere un ingegnere della sicurezza da sei cifre. Ti permette di:
- Scalare con la tua crescita: Man mano che aggiungi più regioni cloud o nuovi prodotti, l'automazione si adatta alla tua crescita.
- Ridurre l'"Attrito di Sicurezza": Gli sviluppatori ricevono feedback in tempo reale. Non devono aspettare un report trimestrale per scoprire di aver sbagliato una configurazione a gennaio.
- Dimostrare Maturità ai Clienti: Quando un cliente enterprise chiede: "Come gestite la sicurezza?", mostrare loro una dashboard live della tua superficie di attacco e del tuo MTTR (Mean Time to Remediation) è molto più impressionante che mostrare loro un PDF dello scorso ottobre.
FAQ: Tutto Quello Che Devi Sapere Sulla Mappatura Della Superficie Di Attacco
D: La scansione automatizzata non farà scattare allarmi o bloccherà i miei server? R: Gli strumenti professionali, come Penetrify, utilizzano la scansione "non distruttiva". Identificano servizi e versioni senza tentare di bloccare il sistema. A differenza di un brutale attacco DDoS, queste scansioni sono progettate per essere chirurgiche e sicure per gli ambienti di produzione.
D: In cosa è diverso da un normale scanner di vulnerabilità? R: Uno scanner standard di solito richiede di specificare cosa scansionare (ad esempio, "Scansiona questo IP"). La mappatura della superficie di attacco trova gli IP per te. Inizia con la scoperta, mentre gli scanner standard iniziano con un elenco di obiettivi.
D: Devo installare agenti sui miei server perché funzioni? R: No. La bellezza della mappatura della superficie di attacco è che è "agentless". Visualizza la tua azienda dall'esterno, proprio come farebbe un hacker. Ciò significa che può trovare asset di cui non sapevi nemmeno l'esistenza, asset su cui non sarebbe mai stato installato un agente.
D: Quanto spesso dovrei mappare la mia superficie di attacco? R: Idealmente, continuamente. Come minimo, ogni volta che distribuisci nuovo codice in produzione o modifichi la tua infrastruttura cloud. In un ambiente DevOps frenetico, le scansioni settimanali sono il minimo indispensabile, ma l'automazione quotidiana è il gold standard.
D: Può aiutarmi con la conformità (SOC 2, PCI DSS, HIPAA)? R: Assolutamente. La maggior parte dei framework di conformità richiede di mantenere un inventario degli asset ed eseguire valutazioni regolari delle vulnerabilità. La mappatura automatizzata fornisce una traccia di audit verificabile che dimostra che stai monitorando il tuo perimetro e risolvendo tempestivamente i rischi.
Conclusione: La Visibilità è la Prima Linea di Difesa
La sicurezza è spesso trattata come una serie di muri. Costruiamo un firewall, aggiungiamo MFA, crittografiamo il database. Ma i muri sono inutili se c'è una lacuna nella recinzione che non sapevi esistesse.
Lo Shadow IT è la "lacuna nella recinzione". È il server di test dimenticato, la pagina di marketing non autorizzata e l'API non documentata. Questi non sono solo problemi tecnici; sono rischi aziendali. Nelle mani di un attaccante motivato, un singolo asset dimenticato può portare a una violazione su vasta scala, con conseguente perdita di fiducia dei clienti, multe ingenti e una reputazione rovinata.
L'unico modo per fermare lo Shadow IT è smettere di indovinare e iniziare a mappare. Abbracciando la mappatura automatizzata della superficie di attacco, passi da una posizione reattiva ("Spero di essere al sicuro") a una proattiva ("So esattamente cosa c'è là fuori").
Non aspettare un audit manuale per scoprire di essere stato esposto per mesi. Prendi il controllo del tuo perimetro oggi stesso.
Sei pronto a vedere cosa si nasconde realmente nel tuo cloud? Smetti di indovinare e inizia a scoprire. Visita Penetrify per automatizzare la mappatura della tua superficie di attacco e trasformare la tua "Shadow IT" in "Visible IT". Proteggi il tuo perimetro, semplifica la tua conformità e dormi sonni tranquilli sapendo che le tue porte secondarie sono chiuse a chiave.