23 agosto 2010

Spanair, malware y gestión del servicio

Aunque a estas alturas seguro que ya habéis oido hablar del tema, parece ser que ha saltado la noticia sobre un troyano que pudo intervenir en el accidente aéreo de Spanair, infectando el sistema que gestionaba los registros sobre incidencias técnicas en los aviones e impidiendo a los técnicos de mantenimiento percatarse de que existían incidencias repetitivas asociadas a uno de los dispositivos que, según parece, intervino en la causa del accidente.

Más allá de los titulares sensacionalistas que hemos podido ver en algunos medios, que poco menos que afirman que el virus fue el causante del accidente, es evidente que cuanto mayor es la dependencia que tiene la actividad humana diaria de los sistemas de información más probabilidades habrá de que un virus informático acabe afectando a dicha actividad, con consecuencias cada vez más imprevisibles. No es la primera vez que en este blog hablo del tema, y de hecho hay una etiqueta específica, seguridad y salud, bajo la que se agrupan esos post. Sin embargo, hoy no tengo intención de profundizar en este caso en cuestión, ya que creo que el nivel de incidencia que pudo tener es bastante relativo (puede contribuir al desastre, por supuesto, pero no creo que sea uno de los factores más importantes, al menos por la información a la que he podido acceder).

Lo que sí que quiero destacar es el concepto ITILero que subyace en el funcionamiento del sistema de gestión de incidencias técnicas de Spanair, y que según parece computa automáticamente una incidencia repetitiva de manera especial (mediante una "alarma"). El funcionamiento es bastante similar a la gestión de incidentes (o alguien prefiere hablar de incidencias?) y su escalado a "problemas" que se utiliza en el mundo de la gestión de servicios TI. También parece que la práctica habitual a la hora de registrar los incidentes permitía demorar dicho registro durante 24 horas, lo que implica que la catalogación como problema puede retrasarse 24 horas. ¿Son esas 24 horas un tiempo aceptable para la detección de problemas originados por incidentes repetitivos? O dicho de otro modo... ¿Debería haberse fijado un SLA asociado al tiempo de generación de una alarma provocada por un incidente repetitivo? Y si Spanair considerase que el tiempo es insuficiente, y que los incidentes deberían registrarse en tiempo real... ¿Cuál sería el coste de la infraestructura necesaria para que los técnicos pudieran registrar los incidentes de forma inmediata?

Con estas dos preguntas lo que quiero destacar es el hecho de que muchas veces, cuando pensamos en gestión de servicios TI, nos limitamos a seguir las prácticas comúnmente aceptadas, sobre todo a la hora de fijar indicadores y SLAs, sin pararnos a reflexionar en las necesidades específicas que puede tener nuestra organización a causa de la actividad que realiza. Sencillamente, el indicador que le conveniene a nuestro negocio no tiene por qué ser un indicador "clásico". Pero tampoco podemos "perder el norte" y subir los niveles de exigencia de los SLAs a valores hiper-exigentes, a riesgo de que el coste asociado a su consecución sea inasumible. Lo que sí debería ser exigible es que las organizaciones estuvieran obligadas a hacer esa reflexión, y que en este caso Spanair pudiera justificar el motivo por el cual sus protocolos de actuación funcionaban de ese modo. ¿Habrá hecho la compañía este ejercicio? Seguiremos atentos a la evolución de los acontecimientos...

4 comentarios:

Miguel Ángel Hernández Ruiz dijo...

Hola Joseba,

Antes de nada, espero que el verano este yendo bien ;).

Como te me has adelantado te dejo aqui mi opinión. La cuestión es que a mi esto me suena a escurrir el bulto, atribuir el accidente a causas externas "fuera del control de la compañía", pero además con un toque de locura transitoria sin sentido que les puede poner las cosas peor aún que estaban. ¿Una compañía aérea con ordenadores llenos de troyanos?, no estamos hablando de la tienda de golosinas de la esquina, lo que hay en juego es algo tan ireemplazable como vidas humanas y tras cada una de ellas hay una tragedia. Y lo que es peor aún, Spanair no había hecho un buen análisis de riesgos porque si se hubiera realizado se habría detectado la criticidad de la no existencia de alarmas en el peor de los casos de forma inmediata por la dimensión de disponibilidad. ITIL e ISO 27001 se complementan a la perfección aportando una la visión de riesgo que la otra precisa para sus procesos de gestión.

Es una verdadera lástima que tengan que ocurrir estas cosas para que la gente vuelva su mirada hacia la seguridad de la información y la prestación del servicio, si es que lo hacen.

Aplicables son también aquí las conclusiones que expuse en este post:

http://www.miguelangelhernandez.es/?p=498

Un Saludo y feliz verano

Joseba Enjuto dijo...

La verdad es que, viéndolo desde nuestro punto de vista, parece evidente que el análisis de riesgos hecho por Spanair podría ser incorrecto, aunque... ¿Quién podía pensar que una no-detección o una detección tardía de una alarma de este tipo (seguro que son mucho más habituales de lo que nos gustaría pensar) podía acarrear vidas huamanas? No quiero hablar de cisnes negros, ya que creo que no es el caso, pero creo que puede surgir un debate interesante: ¿Qué nivel de optimismo/pesimismo tenemos que aplicar a un análisis de riesgos?

Anónimo dijo...

Troyano o no, ese avión tenía que haberse quedado en tierra. Va siendo hora de que terminen con esta farsa. Sabían que fallo tenía el avión y aún asì se arriesgaron a despegar igual por no cancelar el vuelo y ocurrió la tragedia.

Joseba Enjuto dijo...

A posteriori cualquier análisis es sencillo... En el fondo, estamos ante el eterno debate de "Seguridad Vs Operatividad". ¿Cuál es el nivel apropiado de seguridad que debe aplicar una compañía aérea? Desde fuera es fácil proponer, por ejemplo, que siempre que haya una incidencia en un avión, ese avión no vuele... pero claro, los pasajeros de ese vuelo cancelado no viajarán, la compañía no ingresará el vuelo... ¿Y si luego la incidencia era insignificante? Pero... ¿Y si era vital? Discernir entre esas tipologías de incidentes es un arte, y precisamente ahí radica el "alineamiento con el negocio" que se pide a la seguridad.