Sì crittografare, è facile. Inoltre, secondo uno studio del 2014 del Software Engineering Institute, uno su quattro ha avuto un attacco da qualcuno all'interno dell'azienda con un danno medio del 50% superiore a quello di un attore esterno.

Link al sorgente: link Anche se questa è la versione 2017.

What are the real world chances that someone would steal his identity?

L'esecuzione di un attacco MITM su una connessione HTTP quando si trova sulla stessa LAN è fondamentalmente banale. ARP non è progettato per essere sicuro. Alcuni switch di fascia alta forniscono una ragionevole attenuazione, ma per lo più sono piuttosto deboli su tutto ciò che non è favolosamente costoso.

There is an employee complaining that he doesn't like sending his credentials in plain text over the network and that he cannot take responsibility for his network identity in such case.

Se il ragazzo è responsabile per le azioni che vengono prese con le sue credenziali, è ingiusto non prendere precauzioni ragionevoli per proteggere quelle credenziali da altri dipendenti. Potrebbero essere al sicuro da attori esterni a causa dell'isolamento della rete, ma probabilmente non è quello di cui il ragazzo è preoccupato ...

Sì, devi crittografare le tue connessioni. Facciamo uno scenario in cui ritieni che la tua rete sia fisicamente protetta (con la necessaria sicurezza fisica e altre misure di sicurezza richieste) e nessun accesso a Internet (dato che hai indicato che permetti solo l'accesso VPN a fonti attendibili), ma assumiamo che i dipendenti prendano il loro laptop casa e connessione a internet. C'è la possibilità che qualsiasi malware venga implementato senza la loro notifica. E questo malware potrebbe diventare attivo quando è connesso alla rete aziendale e ha iniziato a sniffare il traffico. Ciò porterebbe all'esposizione di tutte le comunicazioni aziendali, comprese le credenziali di tutti.

Quindi è sempre consigliabile crittografare il traffico sensibile.

Ulteriore studio di CA (Insider Threat Report - 2018) indica i seguenti problemi relativi alle minacce interne (riferimento: link ).

Estrai dal rapporto:

• Il 90% delle organizzazioni si sente vulnerabile agli attacchi interni. I principali fattori di rischio abilitanti includono troppi utenti eccessivi privilegi di accesso (37%), un numero crescente di dispositivi con accesso a dati sensibili (36%) e alla crescente complessità delle informazioni tecnologia (35%).
• Una maggioranza del 53% ha confermato attacchi interni contro i loro organizzazione nei 12 mesi precedenti (in genere meno di cinque attacchi). Il 27% delle organizzazioni afferma attacchi interni sono diventati più frequenti.

• Le organizzazioni stanno spostando l'attenzione sul rilevamento di informazioni privilegiate minacce (64%), seguite da metodi di deterrenza (58%) e analisi e post breach forensics (49%). L'uso del monitoraggio del comportamento degli utenti è accelerando; Il 94% delle organizzazioni utilizza metodi di monitoraggio gli utenti e il 93% monitorano l'accesso ai dati sensibili.

• Le tecnologie più diffuse per scoraggiare le minacce interne sono la perdita di dati Prevenzione (DLP), crittografia, identità e gestione degli accessi soluzioni. Per individuare meglio le minacce interne, le società si schierano Intrusion Detection and Prevention (IDS), gestione dei log e SIEM piattaforme.

• La stragrande maggioranza (86%) delle organizzazioni ha già o sta costruendo un programma di minacce interne. Il 36 percento ha un programma formale in atto per rispondere agli attacchi interni, mentre il 50% è focalizzato su sviluppando il loro programma.

Possibili soluzioni / controlli di mitigazione per attacchi interni sarebbero: Fonte: Rapporto sulla minaccia insider 2018, CA Technologies

Rischio di ripudio

Oltre a tutte le valide risposte sugli impiegati come una minaccia e ai visitatori come una minaccia, penso che devi considerare che il semplice fatto che il traffico non sia criptato è di se stesso una vulnerabilità anche in totale assenza di hacker .

Ti stai preparando per una situazione in cui qualsiasi dipendente che fa qualcosa che non dovrebbero fare (per sbaglio o apposta) e poi viene richiamato può negare che in realtà loro. Normalmente, il manager direbbe semplicemente "sappiamo che eri tu perché eri loggato". In questo caso l'impiegato accusato può ragionevolmente rispondere "il login è inutile e tu lo sai. Chiunque sulla LAN potrebbe aver annusato la mia password e fatto questa brutta cosa fingendosi come me."

Alcune società, soprattutto quelle più grandi che sono state in giro abbastanza a lungo da sviluppare cattive abitudini, hanno grosso modo il seguente modello fallace di sicurezza:

The network is safe as long as nobody else plugs into it and nobody inside is technologically skilled enough to abuse it.

È possibile proteggere in tutti i casi? No, ma i controlli di accesso fisico / edile appropriati possono aiutare a ridurre il rischio. Ma cosa succede se gli ospiti sono ammessi in ufficio per riunioni ecc .; ci sono porte ethernet facilmente accessibili nelle sale conferenze o reti wireless facilmente accessibili, o queste reti sono separate da quelle in cui le credenziali possono volare?

Dipende anche da cosa stai cercando di proteggere. Considera lo scenario peggiore in cui qualcuno (all'interno o all'esterno dell'organizzazione) ruba credenziali in chiaro per un altro utente. Cosa sono in grado di fare? accedere ad infrastrutture critiche o solo ad alcuni server di sviluppo di basso profilo? Se un'identità viene rubata, sei in grado di determinare chi sta utilizzando il login?

Idealmente, tutti userebbero la crittografia ovunque. Ma se le minacce di cui sopra sono all'interno della tua tolleranza al rischio, allora forse non è urgente crittografare le risorse della intranet. A seconda delle dimensioni dell'organizzazione, potrebbe esserci un sovraccarico nella distribuzione di certificati CA e SSL su tutte le risorse. Chiediti cosa è peggio: lo scenario peggiore o mettere in opera per crittografare tutto?

Nel 2018, la risposta dipende dalla tua minaccia e dai risultati dell'analisi del rischio. Che, ovviamente, avete eseguito, identificato gli scenari probabili, valutato e preso una decisione aziendale in base all'impatto e alla frequenza, secondo un metodo statistico o quantitativo appropriato.

Il tuo singolo dipendente, tuttavia, ha effettuato la propria analisi dei rischi personali e ha raggiunto il risultato che hai indicato, ovvero:

he cannot take responsibility for his network identity in such case

E ha perfettamente ragione in quella valutazione. Anche uno sguardo superficiale alla situazione rende chiaro che qualcuno diverso da lui, con capacità tecniche minime, potrebbe impersonarlo.

Per te il rischio aziendale è accettabile (ovviamente, intendo il 2018, che la rete interna non è criptata è una decisione intenzionale e non, per esempio, un caso di noi-sempre-fatto -come-come-quello, giusto?) e potresti avere ragione in questa decisione. Accettare un rischio è un'opzione perfettamente valida.

Per lui il rischio non è accettabile. Si noti che non prende una decisione commerciale per la società con la sua dichiarazione. Prende una decisione personale per se stesso. Ecco perché le due analisi di rischio possono arrivare a risultati diversi: contesto diverso, propensione al rischio, impatti.

La risposta corretta è che ti stai assumendo la responsabilità che si rifiuta di prendere. Eseguendo la rete non crittografata e accettando il rischio, l'azienda si assume la responsabilità dell'identità di rete degli utenti di tale rete, in quanto ha deciso di non proteggerli.

Potrei anche sbagliarmi nelle mie supposizioni sulla gestione dei rischi aziendali, nel qual caso raccomando di fare un'analisi dei rischi di questo fatto particolare (rete interna non criptata) e minaccia (impersonificazione degli utenti) in modo da poter rivedere la decisione di avere una rete non criptata o solidificarla con risultati che dimostrano che proteggere la rete sarebbe più costoso della perdita attesa.

Sì, è necessario crittografarlo all'interno della propria rete aziendale "sicura".

Qualsiasi penetrazione della rete porterà al traffico di snooping, e tutto ciò che non è crittografato è facile per l'attaccante. Credenziali, password, informazioni salariali, piani aziendali, qualsiasi cosa.

Per le storie dell'orrore del mondo reale, cerca solo "sicurezza del movimento laterale" Il guscio duro e croccante, l'interno morbido e gommoso non è più una postura di sicurezza valida per qualsiasi azienda.

Sebbene GDPR abbia pochi requisiti tecnici rigorosi, se si gestiscono le Informazioni personali per i cittadini dell'UE, una soluzione comune per soddisfare la conformità GDPR è mostrare di avere la crittografia sui dati in volo (sulla rete)

La realtà è che, a parte la tua sicurezza fisica, non è troppo difficile accedere alla rete, collegandoti fisicamente a una porta (stai monitorando il tuo personale notturno di pulizia ogni notte?) che ne dici di visitare i venditori?) o, più probabilmente, attraverso una qualche forma di intrusione di rete.

Altri hanno citato il documento BeyondCorp di Google, che vale la pena leggere. link

Essenzialmente, la tua rete "interna" non dovrebbe essere attendibile molto più di quella selvaggia e brutta fuori da Internet.

La crittografia è una posizione difensiva a basso costo e alta ricompensa. Perché non dovresti farlo?

Sì. Dovresti sempre crittografare le connessioni su qualsiasi intranet, proprio come faresti su Internet pubblico.

Il attacco DNS Rebinding pubblicizzato ieri consente a un utente malintenzionato l'accesso completo a qualsiasi risorsa HTTP sull'intranet di una vittima, mediante l'uso di un reindirizzamento DNS da un indirizzo IP controllato da un utente malintenzionato a un IP intranet di corproate (ad esempio 10.0.0.22). (La scansione di uno spazio IP intranet per i servizi HTTP può essere eseguita con altre tecniche , reso più facile con conoscenza dell'IP privato dell'utente affrontare .)

L'unica cosa necessaria per un tale attacco è di trucco la vittima nel caricare una pagina web controllata da un aggressore (o javascript o iframe, ecc.) .

Questo attacco è meglio mitigato con HTTPS, poiché il rebind DNS non corrisponderà al dominio del certificato presentato. Anche se la rimozione degli host virtuali predefiniti sembra attenuare questo particolare attacco, questo attacco mostra semplicemente come l'esposizione di risorse interne su connessioni non crittografate possa trasformarsi in una responsabilità con una vulnerabilità di sicurezza da qualche altra parte. (Non sto nemmeno parlando del gran numero di vulnerabilità Wi-Fi 802.11 che abbiamo avuto alla fine dell'anno scorso. Si prega di non esporre le risorse della rete intranet via wifi!)

Difesa in profondità

Ci sono molte buone risposte qui, ma anche se ti fidi di tutti i tuoi dipendenti completamente (cosa che probabilmente non dovresti), apri la porta a un attaccante esterno e rendi la sicurezza molto più difficile.

Normalmente un utente malintenzionato deve prima entrare in qualche modo nella rete (ciò potrebbe essere fatto in vari modi) e quindi ha bisogno di ottenere un accesso da qualche parte per accedere effettivamente ai dati sensibili. Fornendo le password di accesso non crittografate che volano in giro ovunque, hai appena fatto il secondo passo molto più facilmente. Ora ogni volta che un utente malintenzionato accede alla rete, ha immediatamente accesso alle credenziali di alto livello.

Il concetto da difendere in più livelli è chiamato difesa in profondità - se un attaccante può compromettere un livello, deve ancora violare ulteriori barriere per causare danni.

Quindi, per favore CERCATE CREDENZIALI!

do I need to encrypt access to intranet resources over HTTP?

Sì, se le persone si stanno autenticando contro il servizio.

What are the real world chances that someone would steal his identity?

Non lo so - non ho mai incontrato le persone che lavorano nel tuo ufficio / sono all'interno della portata della sua rete Wifi / potrebbero essere in grado di toccare la tua rete. Non so cosa consideri un "livello accettabile di sicurezza fisica". Non so quanto ti fidi delle "parti fidate". Certamente, il monitoraggio degli indirizzi MAC fa pochissimo da proteggere dallo sniffing della rete.

Quanto sarebbe male implementare TLS?

La critica dei tuoi dipendenti è azzeccata.

Pensaci in questo modo: se ti fidi della tua rete fino al punto in cui le credenziali di crittografia sembrano non necessarie, allora perché hai bisogno di credenziali? Pensi di poter sostituire un modulo di accesso con un campo semplice in cui gli utenti possono digitare il loro nome?

Se la risposta è no, anche l'invio di credenziali non crittografate non è un'opzione, perché in fondo non ti fidi delle tue parti fidate e una password inviata via HTTP non è molto segreta.

Per citare una maglietta: "Fallo e basta!"

• Stai trascorrendo ore nello scambio di stack per giustificare il contrario    spendere $ 7 per un certificato e 20 minuti per proteggere il tuo server.

• Una cosa a cui non hai pensato: come lo sa il dipendente    sta inserendo le sue credenziali nel vero sito Web e non in un    clone del sito che è in esecuzione su un arduino nascosto dietro il    copiatrice che è lo spoofing ARP?

• La parola "conformità" significa qualcosa? PCI / HIPAA / GDPR arriverà a bussare ogni giorno. Se un utente "admin" accede al tuo sito web, DEVI criptare tutte le connessioni o affrontare seri problemi.