viernes, 15 de diciembre de 2017

Cuando el código fuente de tu aplicación no es seguro


Es de reconocida importancia la necesidad de mantener los sistemas de información actualizados para prevenir la mayoría de ataques cibernéticos. La actualización y la instalación de los últimos parches de software es un tema constante de este blog. Como en el caso de Apple que describí hace unos dias.

Si una organización tiene un ciclo de actualización corto, por ejemplo no tardar mas de 48 horas en instalar un parche de software crítico luego de su publicación, la práctica prevendrá muchos de los ataques que “mojan prensa”.

¿Pero que decisión debe tomar la dirección de informática si es sabido que el software que se utiliza es vulnerable pero la vulnerabilidad específica es desconocida? Esta es la situación que enfrentan los usuarios de ArcSight, el reconocido software de administración de eventos e información de seguridad (SIEM por sus siglas en inglés). De acuerdo a Reuters, Arcsight que hasta hace poco era parte de HP (o Hewlett-Packard) permitió al gobierno ruso la inspección del código fuente de este programa con el fin de lograr ventas en ese pais. Esa inspección puede permitir al gobierno ruso descubrir vulnerabilidades que serían de otra manera desconocidas.

Para entender la gravedad de esta situación primero hay que conocer la criticidad de un sistema SIEM. Estos sistemas permite correlacionar eventos –también conocidos como logs- en una red en un momento dado. El tipo de eventos puede incluir ingresos a la red (el común “logearse”), notificaciones del software antivirus, cambio de configuración de usuarios, etc. El número de eventos en una red empresarial mediana puede alcanzar miles de millones en un mes.

El éxito de un equipo de ciberseguridad de una organización depende de la rápida detección de eventos anomálos como intentos de acceso fallidos, y encontrar tales eventos en la miriada de eventos que se generan en una red es como encontrar una aguja en un pajar.  Una vez el sistema SIEM correlaciona un evento anomálo, el analista de seguridad puede identificar una actividad maliciosa y tomar medidas de defensa necesarias como generar alertas, bloquear usuarios o desconectar un computador contaminado. Por lo tanto, si el sistema SIEM tiene fallas de seguridad un hacker puede tomar ventaja de estas vulnerabilidades y pasar desapercibidio.

Dado que es ampliamente reconocido el apoyo del gobierno ruso a grupos cuyas operaciones en Internet son bien dudosas, no es sorprendente el nivel de alarma en los expertos de ciberseguridad especialmente cuando organizaciones de defensa y militares norteamericanas como el pentágono y el ejército de Estados Unidos son usuarios de Arcsight.

Alguien puede argumentar que esa no debe ser una preocupación para entes latinoaméricanos. Y en la mayoría de los casos el argumento es válido. Entidades bancarias, del mercado minorista y grandes superficies posiblemente no ven a grupos de hackers de origen ruso como un adversario de importancia.

Sin embargo, el riesgo para organizaciones de defensa latinoamericanas puede ser bien diferente. Aquellos países de la zona que tienen relaciones poco cordiales o tirantes con países donde el gobierno ruso tiene cierta influencia deberían tener presente este caso.

martes, 5 de diciembre de 2017

Cuando tu parche de software no soluciona una vulnerabilidad


A finales del mes de noviembre, un desarrollador de software turco llamado Lemi Orhan Ergin twitteó que había una falla de seguridad crítica en la última versión del sistema operativo MAC (llamado High Sierra o versión 10.13). 

La criticidad era bastante alta pues permitía a un usuario ganar acceso con derechos de administrador en un computador MAC sin entrar ninguna clave. En el sistema operativo MacOS, como en todos los sistemas basados en Unix, el usuario “root” tiene alto acceso al sistema y por supuesto la situación es considerada gravísima. Quien use esta cuenta puede crear nuevos usuarios, habilitar acceso remoto y evitar la necesidad de acceso físico en un futuro.

Una vez hecho público, otros investigadores confirmaron esta vulnerabilidad y agregaron que era posible explotarla de manera remota. Este hecho convierte esta vulnerabilidad en una de las más serias y de alto impacto de los últimos años y por esta razón Apple liberó muy rápidamente un parche que arreglaba el problema. O eso pensamos todos.

Desafortunadamente, el parche reintroducía la vulnerabilidad descubierta por el desarrollador turco. Y esta es una situación que vale la pena analizar.

Cuando el producto de software que una compañía provee presenta vulnerabilidades de alto impacto, los desarrolladores dedican personal y tiempo valioso en solucionarlas.

Usualmente arreglar una vulnerabilidad puede tomar varias semanas, o incluso meses. El equipo de trabajo debe verificar que el nuevo código arregla la vulnerabilidad, que no introduce nuevas vulnerabilidades y que la funcionalidad no cambia. Esto se logra con el llamado “regression testing”, que no es otra cosa que hacer pruebas al software y su funcionalidad. También debe probarse la seguridad del sistema con los llamados “penetration testing”. Solo después de pasar estos requerimientos, el código que soluciona un problema debe liberarse.

Sin embargo, cuando el problema es en un sistema operativo que es usado por millones quienes toman decisiones se enfrentan a un serio dilema. El equipo debe actuar lo más rápido posible y tener el código listo con el menor número de errores. Quienes desarrollan software saben que este es un delicado balance. En el caso de Apple, es claro que no hubo ciertas verificaciones y que se liberó el parche con la intención de solucionar un problema serio en el menor tiempo posible sin las verificaciones necesarias.

Para mala fortuna de Apple, no se logró el objetivo y la compañía es hoy blanco de burlas y críticas por su falta de cuidado. Los responsables de liberar el código deben estar trabajando afanosamente contra el reloj y bajo la presión de los ejecutivos y el público en general.

Esta es una lección importante de aprender. En ocasiones las presiones financieras o de tiempo obligan a saltarse buenas prácticas que existen precisamente para evitar la ocurrencia de estos problemas. Apple tiene ingentes recursos financieros y este será un traspié más en la larga historia de errores de software que poco daño causará en el mediano o largo plazo.

Sin embargo, la historia puede ser muy diferente para compañías de software con recursos limitados. Para una pequeña empresa las consecuencias no se limitan a costos financieros o la pérdida de un contrato vital, sino que pueden desestabilizar o amenazar la existencia de la empresa misma.