Conosco un'azienda che utilizza molti strumenti di sicurezza interna per diverse funzioni all'interno dell'azienda. La maggior parte se non tutti degli strumenti utilizza certificati autofirmati e non i certificati firmati da una CA. O sono interni o generati dallo strumento stesso.
Le mie domande sono, c'è un argomento per ottenere certificati validi per questi strumenti di sicurezza interni?
Se i certificati non sono validi, gli utenti che utilizzano il sistema probabilmente si abitueranno a selezionare procedere comunque sul loro avviso del browser che non è consigliabile dal punto di vista della sicurezza. Qualsiasi cosa potrebbe essere proxy del traffico e intercettare le credenziali del sistema. Se le credenziali sono integrate con un sistema di autenticazione aziendale, le credenziali potrebbero essere piuttosto utili. Ad esempio, se le credenziali sono limitate a un sistema di log, qualcuno potrebbe cancellare selettivamente i log mentre è connesso come un altro individuo.
È possibile installare il certificato di sistema, installare altri certificati aziendali o installare certificati dalle CA riconosciute. Le persone non dovrebbero essere incoraggiate a ignorare gli avvisi di sicurezza.
Se gli utenti sono utenti esperti nel campo della sicurezza, possono scegliere di fidarsi permanentemente dei certificati autofirmati al primo accesso (Trust al primo utilizzo, proprio come SSH). Ciò impedirà qualsiasi attacco di Man-In-The-Middle contro i sistemi a cui si sono precedentemente collegati.
Tuttavia, un attaccante interno (o malware) potrebbe Man-In-The-Middle una connessione iniziale e presentare il proprio certificato. Poiché gli utenti sono abituati ad accettare e fidarsi di questi certificati autofirmati, è probabile che riuscirà a catturare le credenziali.
Alla fine della giornata dipende dal "profilo di rischio" dell'organizzazione. Se questo è considerato un rischio improbabile (come nella maggior parte delle organizzazioni), i certificati autofirmati sarebbero sufficienti. Un'alternativa sarebbe quella di impostare in modo efficace un'autorità di certificazione interna in cui i certificati vengono rilasciati ai server e firmati da un certificato root (o intermedio) di cui tutti gli utenti si fidano. Tale fiducia può essere impostata dal criterio di gruppo (GPO) sulle reti Microsoft Active Directory.
My questions is, is there an an argument for getting valid certs for these internal security tools?
Se questi strumenti sono utilizzati solo internamente, non è necessario un certificato "reale". Un passaggio intermedio consisterebbe nel generare una radice CA di livello aziendale o dipartimentale e aggiungerla a tutti i browser / sistemi client utilizzati.
Penso che tu stia parlando di strumenti di sicurezza che hanno un'interfaccia web come Beef o strumenti proxy come ZAP o Burp.
Di solito questi strumenti sono in esecuzione localmente e li accedono tramite un browser, in questo caso un certificato autofirmato è perfettamente a posto. Il purpouse di un certificato firmato da un'autorità di certificazione attendibile è che ci si fida della CA, quindi si fida dei certificati firmati da loro. Come hai firmato tu stesso il certificato dello strumento (ho fiducia che tu abbia fiducia in te stesso) puoi sempre verificare che il certificato che vedi nel browser sia quello che tu (o lo strumento) hai fatto
Se lo strumento è condiviso tra più dipendenti e pensi che questo sia un rischio puoi sempre creare la tua autorità di certificazione, creare un certificato per ogni strumento e firmare il certificato del nuovo strumento con esso (Probabilmente dovrai configurare il nuovo certificato). Quindi, installa la CA in tutti i computer che devono accedere allo strumento e non avrai più quei messaggi.
Ecco una guida per creare la tua CA , assicurati di utilizzare una chiave sufficientemente potente
Leggi altre domande sui tag tls certificates