28 noviembre 2009

¿Fail-open o fail-close?

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.

3 comments :

Pj dijo...

Si se caen los dos anti-spam es que se te debe haber ido la luz en el CDP, por lo que la caída de los anti-spam será la menor de tus preocupaciones jejeje

Un saludo

Pj dijo...

Donde dije CDP quería decir CPD :-)

Lorenzo Martínez dijo...

@Pj -> Me refería con que exista un problema hardware de un dispositivo de manera que si tienes otro cacharro al lado, siga funcionando el sistema. En caso de que no haya otro dispositivo, ¿qué alternativas hay? que el servicio que hacía ese cacharro paralice el flujo de datos de sistema completo (fail-close) o que deje de hacer su trabajo pero que no se paralice el tráfico y simplemente, ese análisis, no se haga...

Pero efectivamente y como dices si se va la luz completa de un CPD... está claro que es fail-close, a no ser que haya un centro de procesamiento de respaldo que siga haciendo el trabajo del centro primario.