Auditoría del código puesto en producción. El caso Fannie Mae

Hola,

Estos últimos días se ha hablado mucho de un caso acontecido en la Federal National Mortgage Association (Fannie Mae), a la que parece que no terminan de surgirle problemas en todos los planos. Si no había bastante con el quebranto que sufrió la entidad a raíz del descalabro subprime y el oscuro panorama que se le presenta a la entidad, Fannie vuelve a los titulares con un asunto vinculado a la seguridad lógica.

Los últimos en hacerse eco son los chicos del ISC Sans, que preguntan a los lectores sobre cómo afrontar las auditorías de su código en producción. Para quien no haya visto datos sobre el caso Fannie Mae, comentaros que hace algunos días se detectó en una cadena legítima de código en producción una fracción de código malicioso que podría haber provocado el colapso absoluto de las operaciones de la entidad hipotecaria.

El acusado, Rajendrasinh B. Makwana, había sido despedido en octubre de 2008 por crear scripts no autorizados destinados a realizar cambios en la configuración de los servicios de la entidad. Meses después se ha desactivado una cadena maliciosa, oculta en una cadena legítima, y presuntamente introducida por el trabajador poco tiempo después de ser despedido. Esta cadena, de haberse activado (estaba programada a modo de bomba lógica) habría causado la desactivación de todos los mecanismos de alerta y logins de 4,000 servidores, eliminado también la totalidad de claves root. Asimismo, el componente malicioso estaba pensado para destruir todos los datos de estos servidores, así como parte de las copias de seguridad, para finalizar la traca apagando las máquinas e impidiendo que pudieran ser levantadas en remoto. La estimación es de una semana de parálisis completa de operaciones, cantidad de tiempo suficiente para terminar de hundir a la maltrecha Fannie Mae.

El tema es complejo, ya no sólo por la volumetría, sino por la propia complejidad del código en entornos de largo alcance. En un mainframe bancario, me da igual que sea un Unisys, un z/OS o el sistema que se haya escogido, corren miles de programas y de JCLs, que están siendo sometidos continuamente a modificaciones por parte de grupos muy numerosos de personal de diseño y desarrollo. De hecho, uno de los grandes retos tecnológicos que tiene una explotación de este tipo es precisamente administrar que la planificación de tareas, nuevas o modificadas, sea de calidad, completa y carente de errores, que podrían ser catastróficos: cierres incorrectos de la sesión, contabilidad inconsistente, saldos en cuenta alterados, problemas de consolidación, errores en medios de pago … la lista de problemas es larga, y el carácter secuencial de la planificación implica que un problema en una cadena específica podría, en ausencia de medidas de detección y corrección, hacer que fallen finalmente numerosos procesos interdependientes para el negocio. En un caso extremo, caso de fallar por completo la planificación crítica, se corre el riesgo de que la entidad no pueda abrir sesión y por tanto, que no pueda operar, lo que se traduce en millones de euros de pérdidas por cada hora de parálisis.

En un ambiente distribuido, los problemas son igualmente importantes. Los planificadores son distintos, pero la misión es la misma: ordenar la secuencia de operaciones batch para que cuando llegue la hora de abrir el telón y operar online, todo funcione perfectamente. La producción no admite errores en estas infraestructuras.

En este tipo de entornos es imposible verificar línea a línea el código puesto en producción, con lo que se delega en al menos cuatro grandes medidas para mitigar el riesgo de colocación de código no autorizado. La protección de los fuentes (para impedir su manipulación), la segregación de funciones (impedir que los que diseñan sean los que puedan colocar en producción el código), la existencia de autorizaciones (para establecer una cadena de responsabilidad) y el análisis automatizado de código (para detectar patrones no permitidos)

Quizás el gran problema que yo percibo es que muchas veces la inspección de código está orientada a la localización de violaciones de las buenas prácticas para impedir impacto técnico en la producción, como por ejemplo, el uso de merges y otras operativas en base de datos que sometan a excesiva solicitación a los sistemas, la presencia de cadenas no agrupadas, etc. Pero no siempre se orienta la inspección de código a la localización de patrones maliciosos en los programas y cadenas, con lo que encontrar riesgos como los que han llevado al borde de la parálisis a Fannie Mae es algo plausible en muchas instalaciones.

Dado que los productos de gestión de código y planificación más usuales permiten colocar reglas de detección de patrones no permitidos, mi consejo es emplear estas herramientas para definir progresivamente reglas para localizar acciones potencialmente peligrosas desde el punto de vista de la seguridad. Especialmente teniendo en cuenta que, en ausencia de revisión, entre miles de líneas de cobol o del lenguaje que empleen los programas y cadenas, puede exisitir código incrustado que provoque acciones no deseadas, malintencionadas y teniendo en especial consideración que los productos de planificación suelen correr con privilegios muy elevados (frecuentemente, máximos), con lo que en caso de prosperar la introducción inadvertida de código adulterado, las posibilidades de ejecutar acciones perniciosas son prácticamente infinitas.

Afortunadamente para Fannie Mae, el código malicioso ha sido detectado y retirado. Quizás este sea un buen ejemplo para ilustrar la necesidad de orientar las medidas de control en las explotaciones no sólo al rendimiento y la optimización técnica, sino también a la seguridad.