Hace algún tiempo conversábamos con un VP de Operaciones durante un almuerzo y me contaba que asistió a una charla de Kevin Mitnick, y quedó asombrado por la facilidad con la que los hackers pueden ejecutar estafas y tomar accesos a sistemas. La conversación derivó hacia la concientización de usuarios y por mi parte le comenté lo esencial que era actualizar los sistemas, ¿qué?
Ahí hubo algo que no conectó. Mi interlocutor me comentó que eso no tenía nada que ver con el compromiso de sistemas y que eso era algo ya conocido, sobre todo a nivel de sistemas industriales y contra lo cual no se podía hacer nada, dados los costos tanto en capital como inversión. Había que convivir con ello.
Por lo breve de la conversación, no pude argumentar nada más, quedé con la palabra en la boca. Eché de menos no haber puesto más atención a las charlas de liderazgo sobre los “elevator pitch“ y la importancia del storytelling, pero claramente no supe explicar de forma simple el nexo entre lo uno y lo otro.
En recientes estudios de opinión entre profesionales de seguridad, la estrategia de seguridad a nivel personal que mejor mitigaba el riesgo en su opinión, más que las contraseñas robustas o el factor de autenticación múltiple, resultó ser la actualización de software. En su momento me llamó mucho la atención, pero luego recordé que suelo hacerlo muy a menudo casi sin pensarlo mucho.
Vamos un poco más hacia atrás. Desde la perspectiva del atacante, la primera etapa, de reconocimiento, trata de identificar puertas de entrada hacia su objetivo. Trata de revisar exhaustivamente las características de su blanco, buscando debilidades. Generalmente, si su objetivo es un software antiguo, la tarea se facilita enormemente. ¿Por qué ocurre esto?
Dentro del ciclo de vida del software, es necesario no solo remediar errores del software (bugs), sino también fallas que produzcan comportamientos no deseados que posteriormente se traduzcan en vulnerabilidades de seguridad. Desde que el software es liberado a producción, queda expuesto a este tipo de fallos. Los atacantes comienzan a probar distintas formas para vulnerar la aplicación, usando técnicas que con el tiempo se van volviendo más sofisticadas y fáciles de automatizar.
A medida que el tiempo pasa, se van publicando vulnerabilidades conocidas en el software, parches, actualizaciones, hotfixes, nuevos releases, etc.
Este lapso de tiempo en que el software queda expuesto a ataques, se van sumando las fallas y vulnerabilidades, e irremediablemente pasamos a quedar en una posición mucho más frágil de forma exponencial. Ok, no son solo nuestros temores como profesionales de seguridad, hay que considerar también que nuestros costos de reemplazo van aumentando, al ir integrando estas plataformas obsoletas y haciendo que otras plataformas críticas dependan de estas aplicaciones sin soporte.
Dándole vueltas a este asunto, encontré una frase genial que dice “el software no envejece como el vino, envejece como la leche”.
Creo que la analogía es exactamente la que debí utilizar en aquella conversación.
Comments