Estando en una reunión con un importante y potencial cliente, ha salido a la palestra una de las principales preguntas que gente avezada en el mundo de la seguridad te hace. "Oye perdona, y vuestro producto al tener que estar en medio del tráfico de red para analizarlo, en el caso de un posible fallo (eléctrico o funcional), ¿cómo se comporta? ¿Tiene un comportamiento fail-open o fail-close?"Primeramente quiero diferenciar a qué se refieren estos términos. Dada una infraestructura de red, en la que se encuentran una serie de componentes de filtrado por los que van pasando los paquetes de red hacia sus destinos, los clientes suelen ser reacios a añadir otra caja más en medio que pueda ser otro punto de fallo. Sin embargo, muchos de ellos pueden dar por buena la solución si, en caso de fallo del equipo, el tráfico de red, fluye de forma transparente a su paso por el componente defectuoso. En pocas palabras, que si el cacharro falla, el tráfico de red (sea bueno o malo) no se procesa por ese componente, pudiendo llegar al servidor destino peticiones que, en condiciones normales, serían bloqueadas. Esto es lo que se denomina modo de funcionamiento fail-open.
La filosofía fail-close es justo la contraria. Es decir, si un componente falla, el flujo de red se detiene hasta la recuperación (o sustitución) de este servicio. De esta manera aseguramos que el tráfico recibido en los servidores destino mantiene la integridad en todo momento ante tráfico malicioso.
Imaginad que un sistema antispam o antivirus utilizado para el análisis del correo electrónico, deja de funcionar por el motivo que sea... ¿qué preferimos: quedarnos sin correo hasta solventar el problema, causando un gran impacto en una de las principales herramientas de productividad y negocio de la compañía, o continuar haciendo uso del correo electrónico sin ser conscientes de qué tipo de tráfico (en este caso de correo) se intercambian entre nuestros clientes y empleados?
Ante esta disyuntiva hay defensores de ambas filosofías, y los argumentos en general son los siguientes:
- Los defensores de ser fail-open (que ante un crash de un sistema, siga funcionando sin la funcionalidad de seguridad) dicen: "Prefiero mantener el servicio, la disponibilidad y las herramientas de productividad de mi empresa activas y asumir luego las tareas de análisis del impacto causado por la falta de funcionalidad, antes que perder dinero por causa de un fallo de TI".
- Los defensores del fail-close (ante el crash, se detiene el proceso hasta que se solventen los problemas técnicos) dicen: "Para mí, la seguridad de mis procesos críticos es lo primero, y no puedo/quiero asumir que por tener que abrir las puertas de par en par a tráfico malicioso de Internet, el impacto posterior sea mayor, ya sea por efecto de un virus, troyano o el robo de información sensible (que en condiciones normales de filtrado no habría estado expuesta)".
Desde mi punto de vista profesional, creo que la mejor solución radica en dotar de una buena alta (o altísima) disponibilidad de los componentes de los sistemas que forman parte de los procesos críticos de la compañía (entre otros los de TI), y por supuesto contar con un más que probado plan de contingencia ante desastres (me refiero en el flujo de la información de red en este caso). Es decir, que si de los dos antispams, uno se cae, que haya otro disponible que haga el failover, y si los que se caen son los dos, exista solución alternativa, como por ejemplo disponer de una máquina comodín a la que se le instale una imagen de la solución antispam, o de otro tipo de solución TI que pueda caerse en un momento dado. Desconozco si existen servicios de seguros que se puedan contratar para cubrir la improductividad causada por este tipo de paradas no deseadas, o algún otro tipo de medida que proporcione una compensación con un SLA para volver cuanto antes a funcionar.
