eXcalibur
09-03-2004, 09:10
Un cambio de fecha inesperado afecta las operaciones de una importante empresa. Relato inspirado en hechos reales sobre el control de cambios y sus vulnerabilidades explotadas por el factor humano.
Por Damián Ferrer
Verano en la ciudad. El calor no da respiro a sus habitantes y muchos de los empleados de la "Empresa" están disfrutando sus merecidas vacaciones; aún más esperan ansiosos su turno.
En el departamento de sistemas la situación es similar. A pesar de ello hay actividad en el sector: varios proyectos están llegando a su fin y los sistemas entran en la etapa de implementación en producción. Se han planeado los relevos de personal y se cuenta con todo lo necesario para la salida on-line. La ansiedad va ganando terreno a medida que se acerca la fecha límite. Los proyectos son muy importantes y todos desean cumplir con el cronograma.
Semanas antes de un lanzamiento surge la necesidad de verificar funcionalidades que no han sido probadas apropiadamente. Un servidor de desarrollo se asigna para que programadores y analistas trabajen en los cambios...
Cambios
Uno de los escenarios de prueba requiere cambiar la fecha del servidor y verificar su comportamiento en el momento de la liquidación. A pesar de la resistencia del personal encargado de los servidores, esa misma tarde se cambia la fecha del equipo. Como el servidor no está en producción, no hay mayores preocupaciones y los programadores comienzan con sus pruebas.
Es lunes por la tarde y todavía se oyen las charlas y comentarios del fútbol del fin de semana. Al fin de la jornada laboral todos regresan a sus hogares, sin sospechar siquiera las consecuencias que los cambios tendrían en la red y en su trabajo diario.
Jueves. Tres días en el futuro
Esa misma noche comienzan los problemas. Primero es el sector de mesa de ayuda que recibe llamadas indicando que no es posible trabajar en algunas computadoras; la fecha se adelantó al día jueves, son tres días más y no pueden corregirla.
Interviene el sector de administración de servidores y verifica que la fecha oficial de la red para todos los equipos de ese sistema operativo fue adelantada tres días y procede a actualizar la fecha en el servidor #90. La red esta configurada para que los otros servidores tomen la hora oficial desde este servidor. No se requieren más modificaciones para volver todo a la normalidad y la noche transcurre sin novedad.
Un teléfono celular suena en la autopista
Por la mañana, camino al trabajo, uno de los administradores de red recibe un mensaje en su celular. Se trata de un correo electrónico informando sobre novedades del día jueves. Una rara sensación de vacío recorre su estómago cuando mira el reloj del auto y verifica que es martes por la mañana, y no jueves como indica el mail recibido. Ahora está decididamente preocupado intuyendo lo que puede estar pasando. Rápidamente llama al centro de procesamiento de datos para advertir del problema, pero ya es tarde. Para cuando el administrador finalmente llega a su oficina, la tormenta arrecia.
Pese a la época de vacaciones, la actividad en el centro de procesamiento de datos es intensa. Suenan los teléfonos. Vasos de café vacíos sobre los escritorios y mucha tensión en el ambiente. La magnitud del problema es mucho mayor que la estimación inicial. La mayoría de los puntos de venta de la "empresa" no han podido operar con sus sistemas al percatarse del cambio de hora y peor aún, otros han abierto las operaciones con la fecha del futuro, entregando y recibiendo comprobantes. Afortunadamente para el personal encargado de restablecer la normalidad, sólo las aplicaciones basadas en el sistema operativo de los puntos de venta resultan afectadas. Los sistemas que corren en las otras plataformas son inmunes, dado que sincronizan la hora con otro procedimiento. Pero aún no es posible vender con el sistema.
De vuelta al presente
Finalmente, una vez restablecida la hora oficial y los cambios replicados a todos los puntos de venta, la mayoría de los sitios vuelve a estar "on-line". Queda todavía trabajo para arreglar las localidades en donde se facturó con fecha del futuro, pero ese proceso continuará durante la semana. Para media mañana la situación esta controlada y se despeja el panorama en el centro de cómputos, por lo menos de cara al resto de la "Empresa".
Puertas adentro del sector de sistemas la situación es bien distinta. Es necesario determinar las causas del incidente, los costos del corte operativo y, peor aún, analizar si cuando realmente sea Jueves no volverán a ocurrir inconvenientes por registros duplicados, reglas de correo electrónico, interfaces, etc.
Cuando a media mañana se determinan las causas, no quedan dudas sobre lo ocurrido. Una serie de errores humanos y de procedimientos que podrían haberse evitado o al menos detectado previo a su impacto masivo. Quedan descartadas las sospechas sobre sabotajes, virus, hackers u otras amenazas a la red.
Las causas
Debido a que el servidor encargado de proporcionar y sincronizar la hora oficial tenía problemas con su reloj, sus funciones habían sido derivadas temporalmente al servidor utilizado por los programadores. Este fue el cambio no documentado ni comunicado apropiadamente. Una vez adelantada la fecha para probar los cambios, el efecto fue el mismo de llevar a toda la red de puntos de venta tres días en el futuro.
Cuando empezaron los problemas en la noche del lunes los administradores chequearon y ajustaron la fecha en el viejo servidor horario, sin saber que ya no intervenía en el proceso. Por eso horas después volvió a sincronizar con el servidor de desarrollo y el problema no fue detectado hasta que abrieron los puntos de venta por la mañana.
Reflexión final
Desde el punto de vista de seguridad informática, y mas allá de los cambios no documentados en los servidores, quizás el error más grave haya sido la carencia de mecanismos de control y monitorización de la hora oficial de la empresa. Si se hubiera contado con estas alertas, seguramente el incidente hubiera tenido un impacto muchísimo menor.
Por otro lado, vemos un ejemplo de que la seguridad informática depende mucho más del factor humano que lo que a veces se está dispuesto a aceptar.
PUBLICADO EN KRIPTOPOLIS
Damián Ferrer
itsecpro en consultant.com
Por Damián Ferrer
Verano en la ciudad. El calor no da respiro a sus habitantes y muchos de los empleados de la "Empresa" están disfrutando sus merecidas vacaciones; aún más esperan ansiosos su turno.
En el departamento de sistemas la situación es similar. A pesar de ello hay actividad en el sector: varios proyectos están llegando a su fin y los sistemas entran en la etapa de implementación en producción. Se han planeado los relevos de personal y se cuenta con todo lo necesario para la salida on-line. La ansiedad va ganando terreno a medida que se acerca la fecha límite. Los proyectos son muy importantes y todos desean cumplir con el cronograma.
Semanas antes de un lanzamiento surge la necesidad de verificar funcionalidades que no han sido probadas apropiadamente. Un servidor de desarrollo se asigna para que programadores y analistas trabajen en los cambios...
Cambios
Uno de los escenarios de prueba requiere cambiar la fecha del servidor y verificar su comportamiento en el momento de la liquidación. A pesar de la resistencia del personal encargado de los servidores, esa misma tarde se cambia la fecha del equipo. Como el servidor no está en producción, no hay mayores preocupaciones y los programadores comienzan con sus pruebas.
Es lunes por la tarde y todavía se oyen las charlas y comentarios del fútbol del fin de semana. Al fin de la jornada laboral todos regresan a sus hogares, sin sospechar siquiera las consecuencias que los cambios tendrían en la red y en su trabajo diario.
Jueves. Tres días en el futuro
Esa misma noche comienzan los problemas. Primero es el sector de mesa de ayuda que recibe llamadas indicando que no es posible trabajar en algunas computadoras; la fecha se adelantó al día jueves, son tres días más y no pueden corregirla.
Interviene el sector de administración de servidores y verifica que la fecha oficial de la red para todos los equipos de ese sistema operativo fue adelantada tres días y procede a actualizar la fecha en el servidor #90. La red esta configurada para que los otros servidores tomen la hora oficial desde este servidor. No se requieren más modificaciones para volver todo a la normalidad y la noche transcurre sin novedad.
Un teléfono celular suena en la autopista
Por la mañana, camino al trabajo, uno de los administradores de red recibe un mensaje en su celular. Se trata de un correo electrónico informando sobre novedades del día jueves. Una rara sensación de vacío recorre su estómago cuando mira el reloj del auto y verifica que es martes por la mañana, y no jueves como indica el mail recibido. Ahora está decididamente preocupado intuyendo lo que puede estar pasando. Rápidamente llama al centro de procesamiento de datos para advertir del problema, pero ya es tarde. Para cuando el administrador finalmente llega a su oficina, la tormenta arrecia.
Pese a la época de vacaciones, la actividad en el centro de procesamiento de datos es intensa. Suenan los teléfonos. Vasos de café vacíos sobre los escritorios y mucha tensión en el ambiente. La magnitud del problema es mucho mayor que la estimación inicial. La mayoría de los puntos de venta de la "empresa" no han podido operar con sus sistemas al percatarse del cambio de hora y peor aún, otros han abierto las operaciones con la fecha del futuro, entregando y recibiendo comprobantes. Afortunadamente para el personal encargado de restablecer la normalidad, sólo las aplicaciones basadas en el sistema operativo de los puntos de venta resultan afectadas. Los sistemas que corren en las otras plataformas son inmunes, dado que sincronizan la hora con otro procedimiento. Pero aún no es posible vender con el sistema.
De vuelta al presente
Finalmente, una vez restablecida la hora oficial y los cambios replicados a todos los puntos de venta, la mayoría de los sitios vuelve a estar "on-line". Queda todavía trabajo para arreglar las localidades en donde se facturó con fecha del futuro, pero ese proceso continuará durante la semana. Para media mañana la situación esta controlada y se despeja el panorama en el centro de cómputos, por lo menos de cara al resto de la "Empresa".
Puertas adentro del sector de sistemas la situación es bien distinta. Es necesario determinar las causas del incidente, los costos del corte operativo y, peor aún, analizar si cuando realmente sea Jueves no volverán a ocurrir inconvenientes por registros duplicados, reglas de correo electrónico, interfaces, etc.
Cuando a media mañana se determinan las causas, no quedan dudas sobre lo ocurrido. Una serie de errores humanos y de procedimientos que podrían haberse evitado o al menos detectado previo a su impacto masivo. Quedan descartadas las sospechas sobre sabotajes, virus, hackers u otras amenazas a la red.
Las causas
Debido a que el servidor encargado de proporcionar y sincronizar la hora oficial tenía problemas con su reloj, sus funciones habían sido derivadas temporalmente al servidor utilizado por los programadores. Este fue el cambio no documentado ni comunicado apropiadamente. Una vez adelantada la fecha para probar los cambios, el efecto fue el mismo de llevar a toda la red de puntos de venta tres días en el futuro.
Cuando empezaron los problemas en la noche del lunes los administradores chequearon y ajustaron la fecha en el viejo servidor horario, sin saber que ya no intervenía en el proceso. Por eso horas después volvió a sincronizar con el servidor de desarrollo y el problema no fue detectado hasta que abrieron los puntos de venta por la mañana.
Reflexión final
Desde el punto de vista de seguridad informática, y mas allá de los cambios no documentados en los servidores, quizás el error más grave haya sido la carencia de mecanismos de control y monitorización de la hora oficial de la empresa. Si se hubiera contado con estas alertas, seguramente el incidente hubiera tenido un impacto muchísimo menor.
Por otro lado, vemos un ejemplo de que la seguridad informática depende mucho más del factor humano que lo que a veces se está dispuesto a aceptar.
PUBLICADO EN KRIPTOPOLIS
Damián Ferrer
itsecpro en consultant.com