Elegir entre SSH y HTTPS para ejecutar el script utilizando McAfee ESM Nitro

Question

Elegir entre SSH y HTTPS para ejecutar el script utilizando McAfee ESM Nitro

#1 de Stephane (1 votos)
#2 de Jonathan Gray (1 votos)

2

Tenemos la intención de utilizar McAfee ESM Nitro (SIEM) para el monitoreo de seguridad de nuestros servidores de infraestructura. Para llevar la automatización en la administración del sistema de nuestros servidores, hemos desarrollado algunas aplicaciones internas.

Por ejemplo, estamos utilizando una herramienta de terceros para automatizar el sistema que es Ansible y tenemos una aplicación interna que controla cuál de nuestros servidores permanece en producción o quiénes salen de producción.

Ahora intentamos integrar McAfee ESM Nitro con estas dos aplicaciones. De modo que siempre que se genere una alerta de amenaza a través de Nitro, debe usar Ansible o nuestra aplicación interna para ejecutar los pasos de remediación o bloquear el sistema de nuestro entorno de producción.

El Nitro proporciona dos opciones para que dichas acciones se activen contra cualquier alerta. Ya sea para conectarse de forma remota a un servidor mediante SSH y ejecutar cualquier script que se encuentre en ese servidor o que se ejecute a través de cualquier URL a través de HTTPS. Encuentre la instantánea adjunta para ambas opciones.

He leído el hilo en este sitio web donde se analiza la comparación entre SSH y HTTP ( ¿Cuál es la diferencia entre SSL vs SSH? ¿Cuál es más seguro? )

Solicito su consejo profesional sobre qué opción adaptarse y cuál es más segura.

Gracias, Fahad. Opción de URL de fondo de SIEM

cryptography tls ssh siem

pregunta user29752 10.12.2015 - 09:36

fuente

2 respuestas

Lea otras preguntas en las etiquetas cryptography tls ssh siem

¿Por qué las particiones SWAP son buenas para la seguridad? Infraestructura para el análisis de incidentes

score 1 · Answer 1

Depende mucho de cómo se vea su infraestructura y cuánto tiempo y dinero desea invertir (o ya ha invertido) en su infraestructura de seguridad.

Por un lado, SSH es fácil de implementar, requiere autenticación por defecto (por lo tanto, menos espacio para errores) y se puede hacer muy seguro de manera muy fácil. La desventaja es que el aspecto de la seguridad no se escala demasiado bien: la administración de claves en un entorno más grande es complicada y el repliegue predeterminado (aceptar cualquier clave del servidor) es inseguro. La administración de la clave del cliente también es un problema.

Por otro lado, necesita un mayor esfuerzo para implementar HTTPS de manera segura y tiene el mismo nivel de seguridad que lo que obtendría de SSH (suponiendo que esté usando autenticación basada en claves). La ventaja es que es más fácil de escalar: puede usar una PKI privada para administrar claves fácilmente y, una vez que tenga una configuración de trabajo, es muy fácil replicarla de manera segura en tantos sistemas como desee.

score 1 · Answer 2

Personalmente iría con HTTPS (TLS) por los siguientes motivos:

Un sistema basado en alertas / mensajes es mucho más adecuado para un protocolo como HTTP.
Puede configurar una autoridad de certificación (PKI) para manejar la autenticación como una función requerida de TLS.
Puede usar certificados autofirmados para seguridad equivalente a SSH, que luego se puede actualizar a un sistema PKI legítimo.
Puede usar una tecnología basada en web extremadamente poderosa y preexistente, Node.js, para manejar directamente las comunicaciones entrantes y realizar las operaciones internas necesarias. Puede actuar como servidor y como cliente a través de HTTPS.
Las conexiones SSH generalmente terminan dando más acceso al equipo de destino del que se requiere para realizar una tarea, ya que las aplicaciones que implementan SSH suelen ser capaces de realizar un amplio conjunto de tareas. Crear un servidor SSH personalizado no es tan fácil como crear un servidor HTTP personalizado con el mismo nivel de permisos restringido disponible para la aplicación de conexión.