Vedi la nota in basso al centro di questa diapositiva classica:

Questa è da una presentazione di diapositive della NSA trapelata. Togliere il traffico interno non è scienza missilistica, l'unico vero requisito è che qualcuno ti stia prendendo di mira. Se c'è qualcosa di valore che passa attraverso il cavo, qualcosa che potenzialmente vale la pena crittografare, allora potresti anche presumere che qualcuno potrebbe inseguirlo prima o poi.

Ecco perché crittografiamo il traffico interno: i cavi fisici non lo sono essere sempre attendibile. Un ospite in una sala d'attesa che ha accesso alla rete interna (a causa di LAN (V) mancanti o mal configurate) non è raro, o qualcuno che è fidato ma il cui dispositivo è infetto, o qualcuno che entra fisicamente o un singolo server compromesso che può intercettare il traffico di altri server ... ci sono molti scenari in cui la crittografia aiuta, anche su reti interne. Dovresti anche chiederti: la persona meno privilegiata con accesso fisico (o alla rete) è autorizzata ad apprendere i dati più sensibili che la rete trasporta? In caso contrario, la crittografia è ciò che garantisce che non possano intercettarlo.

Sai dove passano i tuoi cavi fisici e se tutti quei luoghi sono sorvegliati in ogni momento? Lo spoofing ARP è disabilitato in ogni LAN che hai? Il salto della VLAN è mitigato? Nessun WiFi WPA2-PSK da nessuna parte? I firewall e i router intermedi hanno 2FA abilitato e non vengono violati? Tutte le misure implementate vengono testate? Non ho dimenticato niente? In base alla mia esperienza, ognuna di queste misure è in uso solo in una minoranza di aziende e pochissime avranno tutto.

La configurazione della crittografia è generalmente facile oggigiorno. Se parli solo dei tuoi dati, puoi correre il rischio per te stesso. Ma quando ci sono altre persone (colleghi o anche clienti) a rischio, dovresti davvero abilitarlo.

L'unico caso d'uso a cui riesco a pensare è se hai utenti non fidati sulla rete ...

Questo, ma il problema è che hai utenti non fidati che non sai nemmeno siano utenti sui dispositivi in ​​rete. Ciò include:

• Nodi botnet su junk IoT compromessa
• Sviluppatori di qualsiasi app abbozzata che hai installato sul tuo telefono o PC
• Attaccanti che hanno già ha compromesso un server effettivo sulla rete, forse uno di basso valore in cui la sicurezza era trascurata
• Attaccanti fisici che hanno collegato discretamente un dispositivo a una presa Ethernet da qualche parte
• Vicini / driver di guardia che hanno indovinato / ha forzato brute la tua password wifi
  • E uno qualsiasi dei precedenti utilizzando i loro dispositivi
• Etc.

Un fondamentale principio di sicurezza è che il livello di rete è sempre non attendibile . Se segui questo, ti risparmierai un sacco di problemi.

Con TLS abilitato per i servizi interni, riduci il rischio di minacce quali:

• Divulgazione di dati sensibili tramite attacchi di sniffing contro un insider maligno o un attaccante esterno che ha già un punto d'appoggio all'interno la tua rete
• Attacchi man-in-the-middle attraverso server non autorizzati che possono facilmente falsificare l'identità di un server non autenticato (TLS ti dà l'autenticità oltre alla riservatezza *) che può quindi intensificare gli scenari di attacco più ampi
• Alterazioni non autorizzate dei dati in transito, che possono causare seri danni se i dati inviati fanno parte di qualche comando amministrativo (TLS fornisce anche il servizio di sicurezza dell'integrità dei dati)
• Probabilmente altri che posso Non penso a adesso ...

* Supponendo che non sia un certificato TLS autofirmato e che esista una sorta di istituzione di fiducia, come una PKI interna.

Come sempre, è un approccio basato sul rischio. Se ritieni che le minacce di cui sopra non siano inverosimili per la tua rete / organizzazione, ti consiglio di implementare TLS ove possibile internamente. Se per qualsiasi motivo ciò aggiungerà uno strato di complessità che supererebbe i benefici ottenuti (poiché il rischio che tali minacce si materializzino è ritenuto basso), non farlo.

A mio parere, è consigliabile proteggere i siti interni sensibili con TLS.

I motivi:

• Se un utente malintenzionato ha ottenuto un punto d'appoggio iniziale a basso privilegio sul tuo rete, avrebbe una superficie di attacco più ampia (tramite packet sniffing e simili) per eseguire l'escalation dei privilegi se le tue pagine di amministrazione non fossero adeguatamente protette.
• Potrebbe essere ingenuo escludere la possibilità di malintenzionati all'interno della rete interna.

TLS dovrebbe essere abilitato per gli utenti che accedono ai servizi (ad es. console di amministrazione) su reti interne?

Sì.

Hai già menzionato la riservatezza contro un cattivo attore interno sulla tua rete con uno sniffer di pacchetti. Questo è un motivo sufficiente proprio lì. Potrebbe essere un dipendente disonesto, un ospite o una stampante compromessa.

Parliamo di quella stampante. Movimento laterale. Una volta che qualcuno "esterno" prende piede nella tua rete, ora è dentro.

TLS offre anche Integrità, oltre che Riservatezza. Impedisce al malintenzionato di modificare i comandi durante il volo nella console di amministrazione.

Infine, TLS fornisce l'autenticazione, almeno del server ai client. Protegge i tuoi utenti dall'accesso a falsi siti di phishing.

Il perimetro di rete "interno" non dovrebbe essere il tuo unico meccanismo di difesa. Questa è l'idea della "difesa in profondità".

Abilitare TLS significherebbe che i dispositivi di monitoraggio non sarebbero in grado di monitorare il traffico poiché verrà crittografato.

Per quanto riguarda il monitoraggio, puoi distribuire la tua CA interna, firmare i certificati TLS con quello e avere i tuoi strumenti di monitoraggio per intercettare e decrittografare il traffico, se questo è un requisito.