Los problemas de ciberseguridad que no podemos ignorar en 2022

Una versión de este artículo se publicó en Infosecurity Magazine. Ha sido actualizado y distribuido aquí.

‍

Los últimos dos años han sido una prueba de fuego para todos, pero el plan de ciberseguridad de la mayoría de las organizaciones se puso a prueba cuando muchos de nosotros pasamos a un modelo de trabajo remoto casi de la noche a la mañana. Realmente tuvimos que subir el nivel y adaptarnos como industria, especialmente ante los actores malintencionados que provocaron un aumento del 300% en los ciberdelitos denunciados desde el inicio de la pandemia.

Todos hemos aprendido algunas lecciones, y me reconforta saber que no solo se está tomando más en serio la ciberseguridad general, sino también la seguridad y la calidad del software a nivel de código. La Orden Ejecutiva de Biden sobre la seguridad de la cadena de suministro de software sacó a la luz problemas críticos, especialmente tras el ataque masivo a SolarWinds. La idea de que todos debemos preocuparnos más por la seguridad y trabajar para reducir las vulnerabilidades con una concienciación sobre seguridad medible es, sin duda, una parte importante de la conversación.

Dicho esto, para combatir a los ciberdelincuentes, debemos ir un paso por delante de ellos, anticipándonos a sus movimientos con una mentalidad preventiva.

Estas son las áreas donde creo que empezarán a causar problemas el próximo año:

El metaverso es una nueva superficie de ataque

El metaverso podría ser la próxima evolución de internet, pero aún falta una transformación similar en la forma en que la mayoría de las industrias abordan la seguridad del software y los entornos digitales.

Si bien los riesgos de ciberseguridad generales, como las estafas de phishing, serán inevitables (y probablemente abundantes mientras todos se familiarizan con el metaverso), la infraestructura y los dispositivos que hacen posible este mundo virtual inmersivo deberán ser seguros. Al igual que los teléfonos inteligentes nos ayudaron a vivir conectados, los periféricos como los cascos de realidad virtual son la nueva puerta de entrada a montañas de datos de usuarios. Se requiere una seguridad de sistemas integrados cada vez más compleja para hacer que los dispositivos IoT sean seguros, y el nuevo y valiente mundo de la realidad virtual y aumentada convencional no es una excepción. Como hemos visto con la vulnerabilidad Log4Shell, errores simples a nivel de código pueden convertirse en un pase libre para los atacantes, y en una realidad simulada, cada movimiento genera datos que pueden ser robados.

Aunque todavía está en sus inicios, un metaverso exitoso requerirá la adopción práctica de criptomonedas (no solo la acumulación aleatoria de la última moneda de moda) y artículos de valor como los NFT, lo que significa que nuestra riqueza, identidad, datos y medios de vida en la vida real quedan potencialmente expuestos a un nuevo "Salvaje Oeste" que puede poner a las personas en riesgo. Antes de que los ingenieros empecemos a volvernos locos con funciones y mejoras épicas, minimizar esta nueva y vasta superficie de ataque desde cero debería ser una prioridad.

Legislación tras Log4Shell

Para la gran cantidad de desarrolladores que se vieron sumidos en el caos, tratando desesperadamente de encontrar si había alguna instancia o dependencia asociada con una versión explotable de la herramienta de registro Log4j, tan utilizada, no creo que el periodo festivo haya sido un momento alegre.

Este ataque de día cero está entre los peores registrados, con comparaciones entre Log4Shell y la devastadora vulnerabilidad Heartbleed de OpenSSL, que todavía se sigue explotando más de seis años después. Si esta línea de tiempo sirve de referencia, lidiaremos con la resaca de Log4Shell durante mucho tiempo. Está claro que, incluso con las lecciones aprendidas de Heartbleed (al menos en cuanto a la necesidad de implementar parches lo más rápido posible), muchas organizaciones simplemente no actúan con la suficiente rapidez para mantenerse protegidas. Dependiendo del tamaño de la empresa, la aplicación de parches puede ser increíblemente difícil y burocrática, requiriendo documentación e implementación entre departamentos. A menudo, los departamentos de TI y los desarrolladores no tienen un conocimiento enciclopédico de todas las bibliotecas, componentes y herramientas en uso, y se ven limitados por estrictos calendarios de despliegue para minimizar las interrupciones y el tiempo de inactividad de las aplicaciones. Existen razones válidas para este método de trabajo (nadie quiere estropear algo y causar un problema), pero parchear demasiado lento es ponerse en bandeja.

Al igual que el ataque a SolarWinds cambió las reglas del juego para la cadena de suministro de software, predigo que ocurrirá algo similar tras Log4Shell. Aunque ya existen mandatos y recomendaciones de gestión de parches en algunos sectores críticos, una legislación generalizada es otra historia. La seguridad de software preventiva siempre será nuestra mejor oportunidad para evitar por completo los parches de seguridad urgentes, pero las mejores prácticas de seguridad dictan que la aplicación de parches es una medida prioritaria no negociable. Creo que este será un tema candente y conducirá a recomendaciones claras para parchear rápida y frecuentemente.

Más énfasis en la seguridad arquitectónica (y los desarrolladores no están preparados)

El nuevo OWASP Top 10 2021 incluyó algunas novedades importantes, además de una sorpresa: las vulnerabilidades de inyección cayeron del primer puesto a un modesto tercer lugar. Esas nuevas incorporaciones hablan de una especie de "segunda etapa" en el camino del desarrollador hacia la codificación segura y las mejores prácticas de seguridad y, lamentablemente, la mayoría no está preparada para reducir el riesgo de manera efectiva a menos que reciba la formación adecuada.

Sabemos desde hace tiempo que los desarrolladores deben tener conocimientos de seguridad si queremos combatir los errores de seguridad comunes en el código, y las organizaciones están respondiendo mejor a la premisa de la prevención impulsada por el desarrollador. Sin embargo, con el Diseño Inseguro ocupando un lugar en el OWASP Top 10 y siendo una categoría de problemas de seguridad arquitectónica en lugar de un solo tipo de error de seguridad, los desarrolladores deberán ir más allá de lo básico una vez que lo hayan dominado. Los entornos de aprendizaje que cubren el modelado de amenazas (idealmente con el apoyo del equipo de seguridad) alivian la presión una vez que los desarrolladores han adquirido las competencias necesarias, pero tal como están las cosas, existe una brecha de conocimiento significativa para la mayoría de los ingenieros de software.

Contrarrestar esto es una tarea colectiva, y la organización puede desempeñar un papel en la creación de una cultura de seguridad positiva para los desarrolladores, fomentando su curiosidad sin causar interrupciones importantes en su flujo de trabajo.