Una versión de este artículo se publicó en Revista Infosecurity. Se ha actualizado y sindicado aquí.

‍

Los dos últimos años han sido una especie de bautismo de fuego para, bueno, todo el mundo, pero el proyecto de ciberseguridad de la mayoría de las organizaciones se puso a prueba cuando muchos de nosotros nos vimos abocados a un modelo de trabajo a distancia prácticamente de la noche a la mañana. Tuvimos que subir la apuesta y adaptarnos como industria, especialmente a raíz de los actores de amenazas desesperadas que provocaron un aumento del 300% en los delitos cibernéticos denunciados desde que comenzó la pandemia.

Todos hemos aprendido algunas lecciones, y me reconforta el hecho de que no sólo 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 cuestiones críticas, especialmente a raíz de la brecha masiva de SolarWinds. La idea de que todos debemos preocuparnos más por la seguridad y trabajar para reducir las vulnerabilidades con una concienciación de seguridad mensurable es definitivamente una parte mayor de la conversación.

Dicho esto, cuando se trata de luchar contra los ciberdelincuentes, tenemos que estar lo más cerca posible de ellos, adelantándonos a sus juegos con una mentalidad preventiva. 

Aquí es donde creo que podrían empezar a hacer olas en el próximo año:

El metaverso es una nueva superficie de ataque

Puede que el metaverso sea la próxima evolución de Internet, pero todavía no se ha producido una transformación similar en la forma en que la mayoría de las industrias abordan la seguridad del software y los entornos digitales. 

Mientras que los problemas generales de ciberseguridad, como las estafas de phishing, serán inevitables (y probablemente abundantes mientras todo el mundo se familiariza con el metaverso), la infraestructura y los dispositivos reales que hacen posible este mundo virtual inmersivo tendrán que ser seguros. Al igual que los teléfonos inteligentes nos ayudaron a vivir en línea, los periféricos como los auriculares de RV son la nueva puerta de entrada a montañas de datos de los usuarios. La seguridad de los sistemas embebidos, cada vez más compleja, es necesaria para hacer que los gadgets del IoT sean seguros, y el nuevo mundo de la RV/AR no es una excepción. Como hemos visto con el exploit Log4Shell, los simples errores a nivel de código pueden convertirse en un pase entre bastidores para los actores de la amenaza, y en una realidad simulada, cada movimiento crea datos que pueden ser robados.  

Aunque está en sus inicios, un metaverso exitoso va a requerir la adopción práctica de criptomonedas (no sólo el acaparamiento aleatorio de la última moneda meme), y artículos de valor como los NFT, lo que significa que nuestra riqueza, identidad, datos y medios de vida de la vida real están potencialmente abiertos a un nuevo "salvaje oeste" que puede poner a la gente en riesgo. Antes de que los ingenieros empiecen a enloquecer con características y mejoras épicas, minimizar esta nueva y vasta superficie de ataque desde el principio debería ser una prioridad.

Legislación a raíz de Log4Shell

Para las decenas de desarrolladores que se vieron sumidos en el caos, luchando por encontrar si había alguna instancia o dependencia asociada a una versión explotable de la ampliamente utilizada herramienta de registro Log4j, no creo que el período de vacaciones haya sido un momento de alegría. 

Este ataque de día cero es uno de los peores de los que se tiene constancia, y se han hecho comparaciones entre Log4Shell y la devastadora vulnerabilidad Heartbleed de OpenSSL, que sigue siendo explotada más de seis años después. Si nos guiamos por esta línea de tiempo, tendremos que lidiar con la resaca de Log4Shell durante mucho tiempo en el futuro. Está claro que incluso con las lecciones aprendidas de Heartbleed -al menos en términos de la necesidad de desplegar e implementar parches tan rápido como sea posible- muchas organizaciones simplemente no actúan lo suficientemente rápido 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. Muy 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 obstaculizados por estrictos calendarios de despliegue para minimizar las interrupciones y el tiempo de inactividad de las aplicaciones. Hay razones válidas para este método de trabajo (léase: nadie quiere estropear el trabajo y romper algo), pero parchear con demasiada lentitud es ser un blanco fácil.

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

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

El nuevo Top 10 2021 de OWASP tuvo algunas nuevas adiciones significativas, así como una sorpresa con la caída de las vulnerabilidades de inyección desde el primer lugar a un humilde tercer lugar. Estas nuevas adiciones hablan de una especie de "segunda etapa" en el viaje de un desarrollador en la codificación segura y las mejores prácticas de seguridad, y por desgracia, la mayoría están mal equipados para hacer un impacto positivo en la reducción del riesgo aquí, a menos que estén debidamente capacitados.

Hace tiempo que sabemos que los desarrolladores deben tener conocimientos de seguridad si queremos combatir los errores de seguridad más comunes en el código, y las organizaciones están respondiendo mejor a la premisa de la prevención impulsada por los desarrolladores. Sin embargo, dado que el diseño inseguro ocupa un lugar en el Top 10 de OWASP y que se trata de una categoría de problemas de seguridad arquitectónica más que de un único tipo de error de seguridad, los desarrolladores tendrán que 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- eliminan una gran presión una vez que los desarrolladores están capacitados, pero tal como está, es una brecha de conocimiento significativa para la mayoría de los ingenieros de software.

Para contrarrestar esto "se necesita un pueblo", y la organización puede desempeñar un papel en la creación de una cultura de seguridad positiva para los desarrolladores, invitando a su curiosidad sin causar grandes trastornos en su flujo de trabajo.