Sé de una compañía que tiene muchas herramientas de seguridad internas para diferentes funciones dentro de la empresa. La mayoría, si no todas de las herramientas están utilizando certificados autofirmados y no certificados firmados por una CA. O bien son internos o generados por la propia herramienta.
Mi pregunta es, ¿existe algún argumento para obtener certificados válidos para estas herramientas de seguridad internas?
Si los certificados no son válidos, es probable que los usuarios que usan el sistema se acostumbren a seleccionar continuar de todos modos en la advertencia de su navegador, lo cual no es recomendable desde una perspectiva de seguridad. Cualquier cosa puede ser proxy del tráfico e interceptar las credenciales del sistema. Si las credenciales están integradas con un sistema de autenticación corporativo, las credenciales podrían ser bastante útiles. Si las credenciales se limitan a un sistema de registro, por ejemplo, alguien podría borrar los registros de forma selectiva cuando haya iniciado sesión como otro individuo.
Puede instalar el certificado del sistema, instalar otros certificados corporativos o instalar certificados de CA reconocidas. No se debe alentar a las personas a ignorar las advertencias de seguridad.
Si los usuarios son usuarios expertos en el campo de la seguridad, entonces pueden elegir confiar permanentemente en los certificados autofirmados en el primer acceso (Trust On First Use, como SSH). Esto evitará cualquier ataque Man-In-The-Middle contra sistemas a los que se hayan conectado previamente.
Sin embargo, un atacante interno (o malware) podría ser una conexión inicial de Man-In-The-Middle y presentar su propio certificado. Dado que los usuarios están acostumbrados a aceptar y confiar en estos certificados autofirmados, es probable que tenga éxito en la captura de credenciales.
Al final del día, depende del "perfil de riesgo" de la organización. Si esto se considera un riesgo improbable (como en la mayoría de las organizaciones), los certificados autofirmados serían suficientes. Una alternativa sería configurar efectivamente una Autoridad de Certificación interna donde los certificados se emitan a los servidores y estén firmados por un certificado raíz (o intermedio) en el que confían todos los usuarios. Dicha confianza se puede establecer mediante una política de grupo (GPO) en las redes de Microsoft Active Directory.
Mi pregunta es, ¿existe un argumento para obtener certificados válidos para estas herramientas de seguridad internas?
Si estas herramientas se usan solo internamente, entonces no necesita un certificado "real". Un paso intermedio sería generar una raíz CA de la empresa o departamento y agregarla a todos los navegadores / sistemas cliente utilizados.
Creo que estás hablando de herramientas de seguridad que tienen una interfaz web como Beef o herramientas proxy como ZAP o Burp.
Por lo general, estas herramientas se ejecutan localmente y acceden a ellas a través de un navegador, en este caso, un certificado autofirmado está perfectamente bien. El propósito de un certificado firmado por una autoridad certificadora de confianza es que confía en la CA, por lo que confía en los certificados firmados por ellos. Como usted mismo ha firmado el certificado de la herramienta (supongo que confía en usted mismo), siempre puede verificar que el certificado que ve en el navegador es el que usted (o la herramienta) realizó
Si la herramienta se comparte entre varios empleados y cree que esto es un riesgo, siempre puede crear su propia autoridad de certificación, cree un certificado para cada herramienta y firme con ella el certificado de la nueva herramienta (Probablemente necesitará configurar la nueva certificado). Luego simplemente instale su CA en todas las computadoras que necesitan acceder a la herramienta y no volverá a recibir esos mensajes.
Aquí hay una guía para crear su propia CA , solo asegúrate de usar una tecla lo suficientemente fuerte
Lea otras preguntas en las etiquetas tls certificates