Para este miércoles tenemos una entrada de Antonio Sanz, Ingeniero Superior de Telecomunicaciones y Master en ICT por la Universidad de Zaragoza.
Actualmente es el Responsable de Sistemas y Seguridad del I3A (Instituto de Investigación en Ingeniería de Aragón), y trabaja como perito en informática forense. Posee las certificaciones CISA, CISM, CHFI e ITILf, y sus áreas de interés actuales son la respuesta ante incidentes, la informática forense y el cibercrimen. Tuitea como @antoniosanzalc y es un imprescindible en cuestiones de ciberseguridad, cibercrimen y APTs entre otros aspectos, dándole una perspectiva geopolítica sumamente interesante.
El fin de vida de Windows XP ha traído, está trayendo (y traerá) muchos quebraderos de cabeza tanto a administradores de sistemas como a los expertos en seguridad. En este artículo se pretende ofrecer soluciones y consejos basados en nuestra experiencia en el I3A (Instituto de Investigación en Ingeniería) de la Universidad de Zaragoza.
El primer paso a seguir es definir el objetivo del proyecto y los parámetros de partida. El objetivo principal no debería ser reemplazar Windows XP por otro sistema operativo, sino apoyar los procesos de negocio (en nuestro caso la investigación realizada por nuestros miembros). Ese apoyo se traduce directamente en este caso en una gestión del riesgo, orientada a controlar y reducir el mismo hasta niveles aceptables.
Como parte de los parámetros iniciales se tiene que el proyecto debería terminar lo antes posible (de forma óptima a principios de Abril, cuando se daba por finalizado el soporte). Por razones obvias de la coyuntura económica actual, el gasto a realizar debería de ser el mínimo posible.
Partiendo de esas premisas, en septiembre de 2013 se diseñó un plan de actuación dividido en las siguientes fases:
Comunicación
Se hizo uso de los canales de comunicación habituales (listas de correo internas, página web, redes sociales) para informar a nuestros investigadores de la problemática de seguir haciendo uso de Windows XP, así como de las posibles alternativas que tenían. El objetivo es doble: por un lado concienciar a los usuarios de la necesidad del cambio, e ir recopilando información adicional sobre posibles activos no documentados.
Recogida de datos
El segundo paso a seguir era obtener datos para ser conscientes de la magnitud del problema (el parque informático del I3A se acerca al millar de equipos). Para ello se tomó una aproximación basada en tres líneas de actuación:
- Recogida directa: Se tiene desplegado un sistema de inventario basado en OCS, y todos los equipos de menos de 5 años lo tienen instalado como parte del procedimiento de puesta en marcha (los equipos de más de 5 años lo tienen instalado a medida que han tenido problemas como parte de nuestro procedimiento de servicio técnico). OCS nos permitió fácilmente detectar qué equipos tenían Windows XP, así como sus características hardware (principalmente memoria RAM y procesador).
- Información de los usuarios: Dado que se animó a los usuarios a comunicarnos de forma anticipada su decisión a migrar a otro sistema operativo, fuimos capaces de obtener bastante información (sobre todo de muchos equipos antiguos).
- Exploración de red: Dado que se opera en subredes concretas de la Universidad de Zaragoza, fue posible lanzar la herramienta nmap con las opciones de identificación de sistema operativo, pudiendo obtener (y confirmar) una buena cantidad de información.
Análisis de la información
Toda la recogida de información del paso anterior dio como resultado que aproximadamente unos 200 equipos de nuestro sistema de información tenían instalado Windows XP. Estos equipos podían clasificarse grosso modo en los siguientes grupos:
- Equipos modernos (menos de 3 años de antigüedad), a los que se había hecho un downgrade de Windows Vista a Windows XP por petición del usuario.
- Equipos de usuario viejos (más de 3 años de antigüedad), empleados por los usuarios para tareas de oficina (navegación, correo y ofimática).
- Equipos con software científico viejo, que no tienen por qué ser antiguos pero que corren un software que sí lo es (debido a que no existe versión para Windows XP o si existe no se posee licencia).
- Equipos de laboratorio, casi siempre muy viejos pero que controlaban equipamiento científico y eran críticos para su correcto funcionamiento.
En el caso de los equipos modernos, la línea a seguir era bastante clara: contactar con los usuarios responsables del equipo y planificar una migración a Windows 7.
Para los equipos de usuario viejos se realizaron unas pruebas de rendimiento con Windows 7 y nos encontramos que un equipo de 6-7 años (lo que podría ser un Pentium IV con 1Gb de RAM) funcionaba de una forma similar con Windows 7 que con Windows XP SP3. Se planteó a los usuarios actualizar la memoria RAM de su equipo a 2Gb, lo que mejoraba sensiblemente el rendimiento, y se planificó su migración.
Si el equipo que tenía un software específico para Windows XP era moderno, la opción lógica era probar si se ejecutaba correctamente bajo XP Mode, el sistema operativo virtual de XP que corre bajo Windows 7. Si la respuesta era afirmativa, de nuevo planificábamos la migración de acuerdo con el usuario.
El primer problema que nos encontramos fue con el software antiguo, que o bien no era capaz de correr bajo Windows 7 (en algunos casos era software heredado de Windows 95 que corría en DOS), o bien la licencia adquirida solo ofrecía versiones para Windows XP (siendo necesario asumir un gasto a veces importante para actualizarse a nuevas versiones). En algunos casos el investigador decidió actualizarse, pero en otros casos la negativa era tajante: el equipo debía quedarse como estaba.
Este problema quedó patente en cuanto se empezó a analizar el último grupo: los equipos de laboratorio. En estos casos el problema del software se agrava por el hardware necesario para controlar el equipamiento científico, del que no se disponen drivers para Windows 7 (como caso anecdótico llegamos a tener un ordenador que controlaba un cromatógrafo de gases adquirido en 1997, con tarjeta ISA).
La solución aquí pasaba por la adquisición de un equipo nuevo completo, en muchos casos con adaptadores para poder conectar las tarjetas de control o adquisición de datos, así como el nuevo software (si lo hubiere, que en algunos casos ya no existía) que controlara el equipamiento.
Dado que el coste en estos dos últimos casos era inasumible, mantener en algunos equipos Windows XP era totalmente necesario. Se decidió entonces tomar una serie de medidas básicas para minimizar el riesgo de hacer uso de Windows XP:
- Realizar una imagen del equipo: Dado que la edad del equipamiento superaba en muchos casos los 6-7 años, y que son ordenadores sin ningún tipo de redundancia (y que en muchos casos no se dispone siquiera de una copia en soporte físico del software de control) se realizó una imagen del disco que pudiera ser usada para restaurarlo en caso de fallo hardware o de una intrusión.
- Desconectar el equipo de la red: En la mayoría de los casos el equipo no necesitaba obligatoriamente de conexión a Internet para su funcionamiento, así que se desconectó de la red, haciendo toda la transferencia de datos mediante una memoria USB autorizada (que no debería ser empleada para ningún otro fin). En el caso de que el acceso a red fuera necesario (para conectarse a un servidor de licencias, por ejemplo) se configuró el cortafuegos de Windows para dejar acceso únicamente a la red local.
- Deshabilitar servicios innecesarios: En la mayoría de los casos los equipos venían con una instalación por defecto de Windows XP, por lo que un proceso mínimo de bastionado permitía reducir en gran medida la superficie de ataque.
- Eliminar permisos de administrador: Si un malware ataca el equipo el no disponer de privilegios de administración limita en gran medida las acciones que puede tomar y facilita su eliminación. Sin embargo, esta medida se pudo poner en marcha en una parte reducida de los equipos debido a que buena parte de nuestro software científico requería de privilegios de administración (en muchos casos, incluso de ser ejecutado por el usuario Administrador).
Ejecución de procedimientos
Una vez definidos todos los procedimientos anteriores, se pasó a su ejecución. Los usuarios disponían de un sistema de incidencias en el que podían solicitar su migración a Windows 7, y los técnicos planificaban de forma conjunta las mejores fechas y la operativa de la migración.
De forma paralela, se contactó con los responsables de los equipos de laboratorio para advertirles de la necesidad de la actuación y así poder realizar una planificación que casara con sus necesidades científicas y los recursos del servicio de informática.
Verificación
El proceso se definió en primera instancia como iterativo, por lo que al final de cada iteración se realizaron una serie de comprobaciones para evaluar la eficacia de las actuaciones realizadas. Estas comprobaciones se realizaron a través de las actualizaciones del propio sistema de inventario OCS y a través de nuevos escaneos de la herramienta nmap.
Resultados obtenidos
El proceso ha llevado varios meses de trabajo, en lo que quizás la tarea más ardua ha sido la de concienciar a nuestros investigadores de la necesidad del cambio (la filosofía de “si funciona no me lo toques” junto con el “no tengo ni un euro para gastar” han necesitado de mucho trabajo y persuasión para su derrota). Se han tenido también numerosos problemas técnicos, derivados principalmente de la heterogeneidad de casos de uso por parte de nuestros usuarios y de la limitación existente en el gasto disponible.
Sin embargo, los resultados han merecido la pena: de los 200 equipos con los que se partía en un inicio, el 90% han pasado por el proceso de evaluación y han sido o bien migrados a Windows 7 (70%), o bien bastionados de forma procedimental (20%). El 10% está casi en su totalidad planificado, a la espera de terminar proyectos de investigación para su tratamiento.
Experiencias obtenidas
A lo largo del proceso hemos pasado por multitud de situaciones, pero las conclusiones más útiles para aquellos que quieran “deshacerse” de sus equipos con Windows XP pueden ser las siguientes:
- Recursos disponibles: Hay que disponer de los recursos necesarios para atacar el proyecto. En nuestro caso el personal técnico estaba dedicado simultáneamente a otras tareas de soporte, por lo que el proyecto se alargó más de lo deseable.
- Información, información, información: La parte de recopilación de información es vital, ya que los equipos “ocultos” (nos encontramos con unos cuantos a lo largo del proyecto) no serán procesados. En este caso el disponer de un sistema de inventario es una ayuda vital.
- Concienciación: Sin el apoyo de los usuarios (en nuestro caso la dirección podía recomendar pero no obligar nada) el proyecto no puede progresar. Es necesario incidir en el riesgo que se corre al utilizar Windows XP, así como la sencillez de las opciones disponibles.
- Casos de uso: En algunas organizaciones solo habrá un caso de uso, mientras que en otra puede haber docenas (sobre todo si tratamos de aplicaciones desarrolladas a medida). Es obligatorio hacer un listado de casos de uso y tratar cada uno de forma individualizada.
- Verificación continua: Tener un equipo con Windows XP sigue siendo un riesgo, por mucho que lo hayamos bastionado. Es imperativo el disponer de mecanismos de auditoria que permitan comprobar que dichos equipos siguen funcionando correctamente, así como el poder detectar equipos ocultos (ya sea haciendo uso de herramientas como nmap, monitorizando los logs del proxy de salida, etc.).
En conclusión, el proyecto nos ha permitido reducir nuestra exposición al riesgo en gran medida al sustituir buena parte de las instalaciones de Windows XP de una forma ordenada y razonada con un gasto de recursos muy controlado.
