Un dipendente deve condividere rapidamente alcuni file.
Un team di sviluppo ha bisogno di un ambiente di test.
Il marketing vuole creare una landing page.
Un progetto ha bisogno di un nuovo servizio cloud.
Qualcuno crea semplicemente un account e inizia a utilizzarlo.
Dal punto di vista operativo tutto funziona.
Dal punto di vista della sicurezza, però, potrebbe essere nato un nuovo elemento dell'infrastruttura che nessuno ha inserito nell'inventario.
Questo fenomeno viene comunemente chiamato Shadow IT.
Cos'è lo Shadow IT?
Con Shadow IT si indicano tecnologie, applicazioni, servizi o infrastrutture utilizzati all'interno di un'organizzazione senza essere formalmente gestiti o conosciuti dal reparto IT o dai responsabili della sicurezza.
Può trattarsi di:
- servizi SaaS;
- cloud;
- server;
- applicazioni web;
- repository;
- strumenti di collaborazione;
- storage;
- domini;
- ambienti di sviluppo.
Non significa necessariamente che qualcuno stia facendo qualcosa di scorretto.
Spesso nasce semplicemente dalla necessità di lavorare velocemente.
Un esempio
Un team di sviluppo deve creare un ambiente temporaneo.
Invece di passare attraverso il normale processo interno, attiva:
staging.example-provider.com
e collega:
test.example.com
Il progetto viene completato.
Il team si concentra sulla produzione.
Dopo qualche mese, l'ambiente di test è ancora online.
Il reparto sicurezza, però, non sa che esiste.
Questo è un esempio molto semplice di Shadow IT.
Perché può rappresentare un problema?
Perché un servizio che non è nell'inventario rischia di non essere incluso nei normali processi.
Potrebbe non essere:
- monitorato;
- aggiornato;
- sottoposto a backup;
- incluso nei test di sicurezza;
- protetto secondo gli standard aziendali;
- assegnato a un responsabile.
Ancora una volta, il problema principale è la mancanza di visibilità.
Shadow IT non significa automaticamente vulnerabilità
Questo è importante.
Un servizio creato autonomamente potrebbe essere configurato perfettamente.
Il problema è che l'organizzazione potrebbe non sapere che esiste.
Per questo è utile distinguere:
Shadow IT
↓
Asset sconosciuto
↓
Da identificare
↓
Da valutare
↓
Eventuale problema di sicurezza
Non bisogna trasformare automaticamente la scoperta di un servizio sconosciuto in una vulnerabilità.
Come può essere scoperto?
Una parte dello Shadow IT può diventare visibile attraverso la superficie pubblica.
Per esempio:
DNS
Certificate Transparency
IP pubblici
Hostname
HTTP/HTTPS
Servizi cloud
Supponiamo che l'organizzazione conosca:
www.example.com
api.example.com
ma dall'esterno emerga:
campaign.example.com
Nessuno sa chi lo gestisca.
Questo non dimostra un problema.
Ma è un ottimo punto di partenza per un controllo.
Il ruolo dei domini
I domini e sottodomini sono particolarmente interessanti perché spesso rappresentano il punto di collegamento tra servizi diversi.
Un'organizzazione potrebbe avere:
www.example.com
api.example.com
shop.example.com
support.example.com
campaign.example.com
dev.example.com
e ogni hostname potrebbe appartenere a un team differente.
Senza un inventario centralizzato, è facile perdere la visione d'insieme.
Lo Shadow IT e i servizi di terze parti
Il problema può essere ancora più difficile quando il servizio viene gestito completamente da un provider esterno.
Per esempio:
status.example.com
↓
servizio SaaS
oppure:
campaign.example.com
↓
piattaforma marketing
Il dominio appartiene all'organizzazione, ma l'applicazione viene gestita da un'altra azienda.
Se il progetto viene chiuso senza una corretta procedura di dismissione, il collegamento potrebbe rimanere attivo.
Shadow IT e sviluppo
Gli ambienti di sviluppo sono un'altra fonte comune.
Durante un progetto possono comparire:
dev.example.com
test.example.com
staging.example.com
preview.example.com
Sono nomi perfettamente normali.
Ma dovrebbero essere classificati.
Un ambiente di staging pubblico, per esempio, dovrebbe essere intenzionale e adeguatamente protetto.
Come ridurre il problema
La soluzione non è necessariamente vietare qualsiasi tecnologia non approvata.
Un approccio troppo rigido spesso porta semplicemente le persone a nascondere ancora di più ciò che utilizzano.
È più efficace creare un processo semplice per:
- registrare nuovi servizi;
- assegnare un proprietario;
- definire la loro funzione;
- stabilire se devono essere pubblici;
- monitorarli;
- dismetterli quando non servono più.
Un inventario utile
Un inventario può essere molto semplice:
| Asset | Tipo | Team | Funzione | Pubblico | Stato | | -------------------- | ------- | --------- | -------------- | -------- | ------------- | | api.example.com | API | Dev | API produzione | Sì | Attivo | | staging.example.com | Web | Dev | Test | Sì | Attivo | | campaign.example.com | Landing | Marketing | Campagna | Sì | Da verificare |
La cosa importante non è avere una piattaforma complessa.
È riuscire a rispondere alla domanda:
"Chi sa perché questo servizio esiste?"
Shadow IT e sicurezza continua
Un'organizzazione può avere un ottimo firewall, sistemi aggiornati e procedure di sicurezza molto mature.
Ma se esiste un'applicazione pubblica che nessuno sa di dover proteggere, quella parte dell'infrastruttura può rimanere fuori dal processo.
Per questo la sicurezza moderna non può basarsi esclusivamente su ciò che l'organizzazione sa di avere.
Deve includere anche la capacità di scoprire ciò che è effettivamente visibile dall'esterno.
In sintesi
Lo Shadow IT nasce spesso da una necessità legittima: lavorare più velocemente.
Il problema arriva quando il servizio creato rimane fuori dall'inventario.
La sequenza può diventare:
Nuovo servizio
↓
Nessun inventario
↓
Nessun proprietario
↓
Nessun monitoraggio
↓
Servizio dimenticato
Ed è proprio questa situazione che bisogna evitare.
L'obiettivo non è impedire alle persone di utilizzare nuovi strumenti.
È fare in modo che ogni risorsa pubblica finisca prima o poi sotto il controllo di qualcuno.
MiHakero può contribuire a questo processo osservando ciò che è pubblicamente rilevabile e mettendo in evidenza asset e servizi che potrebbero non essere presenti nell'inventario conosciuto.