El grado de formalidad del análisis de vulnerabilidades en servidores de correo depende de la tarea que se esté llevando a cabo.

En primer lugar, es necesario diseñar el enfoque que se utilizará para monitorear la seguridad de los servidores de correo. En muchos casos es más fácil mirar las soluciones disponibles – hay numerosas empresas que ofrecen servicios de auditoría de seguridad cibernética. Pero en ciertos casos puede ser necesario que usted mismo resuelva el problema. El grado de formalidad de este proceso depende de la tarea que se esté llevando a cabo.

Preparación de la documentación necesaria

En primer lugar, debe decidir qué, por qué y cómo debe verificar. Las tres preguntas son necesarias, porque usted necesita cubrir todo el terreno que pueda con su auditoría, pero sin perder el tiempo en detalles innecesarios.

Qué

Cree una lista de todos los datos (nombres de usuario, listas de contactos, archivos adjuntos, etc.) y parámetros (rendimiento, tiempo de actividad, etc.) que cree que necesita para realizar un seguimiento y comprobar las vulnerabilidades. Esta lista puede dividirse en varias listas de comprobación con diferentes áreas de responsabilidad (servidor, red, sistema operativo). Cada entrada de la lista debe ser ponderada de acuerdo a la magnitud del impacto que puedan causar los problemas potenciales con esta entrada.

Cómo

Tenemos que aplicar dos enfoques:

Utilizando una lista de componentes previamente creada, buscamos herramientas y utilidades que puedan ser utilizadas para comprobar si un componente en particular es vulnerable o no. A cada entrada se le debe asignar una forma correspondiente de comprobar, y como resultado, todas esas formas serán nuestras pruebas, u objetos de control.

Utilizando la lista de vulnerabilidades potenciales, ampliamos nuestra lista de objetos de monitorización con controles adicionales, lo que nos permite comprobar la existencia de dichas vulnerabilidades. En caso de que algunas entradas se repitan, necesitamos marcarlas, pero no eliminarlas.

Por qué

Tenemos que comprobar el objetivo, el peso y el alcance de cada uno de los controles para poder asignarle una prioridad. En esta etapa, podemos eliminar las entradas repetidas de la lista de nuestros componentes, pero sólo si el componente eliminado está totalmente cubierto por alguna otra entrada o su combinación. De lo contrario, mantenemos la entrada repetida, pero le asignamos una prioridad menor.

Después de eso, tenemos que tomar una decisión sobre si cada entrada vale los recursos necesarios para ejecutarla. Necesitamos estimar el tiempo y el dinero necesarios para comprar software, formar a los empleados y ejecutar las comprobaciones. Algunos componentes con prioridad media y baja pueden ser excluidos de la lista si no puede justificar el gasto. Pero no deben ser eliminados completamente de la lista – las prioridades pueden cambiar en cualquier momento.

Planificación de pruebas de seguridad para servidores de correo electrónico

Al crear la lista de controles, lo mejor es utilizar listas de comprobación de NIST SP 800-45.

Después de formar la lista, puede establecer el alcance del trabajo y los recursos necesarios. Dependiendo de la avería, también puede crear un plan detallado que cubra completamente cada procedimiento de principio a fin, cuando cree un informe sobre el estado actual de la seguridad del servidor.

Pruebas (búsqueda de vulnerabilidades)

Con la lista de comprobación, el proceso se reduce a la realización de comprobaciones, que se tratan en las secciones Productos y utilidades de este artículo. El orden de la lista dependerá de la prioridad de la tarea. Si el tiempo es limitado, es necesario verificar los componentes de alta prioridad. Si no hay límite de tiempo, la organización de los cheques sobre la base de lo que es más conveniente puede ahorrar tiempo y dinero.

Algunas verificaciones pueden llevar más tiempo del previsto; en este caso, debe omitirlas y desplazarlas a un pool separado, así como intentar encontrar una forma de optimizar el proceso.

Se deben registrar todos los incidentes en los que se hayan visto comprometidos los datos y la configuración del servidor. Algunos de ellos pueden ser ignorados más tarde, pero en una etapa actual es importante no perder el tiempo tratando de investigar los detalles, sino más bien asegurarse de que la verificación cubra tanto como sea posible durante el tiempo correspondiente.

Análisis de los problemas detectados

El análisis se reduce a la evaluación de riesgos basada en la fórmula – impacto*verosimilitud* exposición. Cada control puede ser puntuado de 1 a 5, donde 5 es una indicación de que este problema no puede ser ignorado, mientras que 1 es una buena indicación de que resolver el problema es probablemente demasiado ineficiente para ser considerado.

El impacto del incidente depende del componente que fue comprometido. En algunos casos puede ser extremadamente pequeño (por ejemplo, el servidor deja de funcionar a los 100 ms), y a veces puede ser extremadamente grande (pérdida de la base de datos). Si las listas de verificación están correctamente construidas, entonces un impacto puede ser superado haciendo referencia a la lista de verificación.

La probabilidad depende de la recurrencia del problema y de la facilidad con que se pueda repetir. Cambia de muy raro (quedarse sin memoria una vez al año mientras se envían cartas constantemente) a estable (siempre al recibir paquetes udp 2²⁵⁶ a través de un puerto tcp abierto).

La exposición depende de si es difícil detectar el problema y si el problema puede ocurrir durante el curso del funcionamiento normal del servidor. La exposición puede variar desde imposible (varios problemas improbables que ocurren al mismo tiempo) hasta inevitable (la palabra “contraseña” utilizada como contraseña de administrador, o servidor caído debido a la recepción de 1000 correos electrónicos).
Estimación del riesgo para la seguridad como impacto * probabilidad * exposición.

Después de la evaluación, todos los problemas se clasifican por riesgo en orden descendente (Impacto * Probabilidad * Exposición). A continuación, cada incidente con un valor de riesgo superior a 8 (al menos) debe ser discutido. La discusión debe ayudar a categorizar los incidentes en vulnerabilidades (amenaza de seguridad cibernética, por ejemplo, pérdida de datos), fallas (una amenaza de pérdida de lealtad, debido a la posesión de datos excesivos, o spam), y problemas ignorados. Las prioridades deben asignarse a cada vulnerabilidad y defecto.

Solucionar las vulnerabilidades

Por lo general, hay tres maneras de solucionar las vulnerabilidades:

1. Cambiar a una versión u otro producto que no tenga el problema.
2. Instalar software adicional que permita eliminar el problema.
3. Desactivar la funcionalidad que muestra el problema.

Lo principal que hay que tener en cuenta es el nivel de los riesgos asociados, los costes y el presupuesto para las reparaciones, así como los recursos necesarios. Todas estas cosas pueden tener un gran impacto en la creación de un programa para las correcciones y la designación del orden de las tareas.

Lo mejor es ocuparse inmediatamente de los problemas que se pueden resolver fácil y rápidamente, sin aplazarlos para más adelante. Las vulnerabilidades complejas pueden tardar varios días en solucionarse, y sería mejor no dejar que los problemas pequeños, pero peligrosos, simplemente esperen su turno.

En algunos casos, puede agrupar las vulnerabilidades que se pueden resolver con una sola solución. Esto puede ahorrarle dinero y tiempo, especialmente si se considera que este enfoque es el más fiable (lo que significa que no requeriría ningún cambio en el futuro). Sin embargo, es mejor no buscar balas de plata, porque pueden resultar más complejas y costosas que varias soluciones simples.

¿Necesita un servidor dedicado de correo seguro y confiable? Conozca aquí cómo podemos ayudarle

Imagen: Wade Lambert on Unsplash