Los problemas de ciberseguridad que no podemos ignorar en 2022

Se publicó una versión de este artículo en Revista Infosecurity. Se ha actualizado y distribuido aquí.

‍

Los últimos dos años han sido una especie de bautismo de fuego para, bueno, todo el mundo, pero el plan de ciberseguridad de la mayoría de las organizaciones se puso a prueba, ya que muchos de nosotros nos sumergimos en un modelo de trabajo remoto prácticamente de la noche a la mañana. Realmente tuvimos que subir la apuesta y adaptarnos como industria, especialmente a raíz de la aparición de amenazas desesperadas provocando un aumento del 300% en las denuncias de ciberdelitos desde que comenzó la pandemia.

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

Dicho esto, cuando se trata de luchar contra los ciberdelincuentes, debemos mantenernos lo más en sintonía posible con ellos, adelantándonos a sus áreas de juego con una mentalidad preventiva.

Aquí es donde creo que podrían empezar a causar sensación el año que viene:

El metaverso es una nueva superficie de ataque

El metaverso podría ser la próxima evolución de Internet, pero aún no se ha materializado 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 escollos generales de ciberseguridad, como las estafas de suplantación de identidad, serán inevitables (y probablemente abundarán mientras todo el mundo se abre paso en el metaverso), la infraestructura y los dispositivos reales que hacen posible este mundo virtual inmersivo deberán ser seguros. Al igual que los teléfonos inteligentes nos ayudaron a vivir en línea, los periféricos, como los cascos de realidad virtual, son la nueva puerta de entrada a una gran cantidad de datos de los usuarios. La seguridad de los sistemas embebidos es cada vez más compleja para que los dispositivos de IoT sean seguros, y el nuevo mundo de la realidad virtual/aumentada convencional no es una excepción. Como hemos visto con el exploit de Log4Shell, los errores simples a nivel de código pueden convertirse en un paso entre bastidores para los atacantes y, en una realidad simulada, cada movimiento genera datos que pueden ser robados.

Si bien está en pañales, un metaverso exitoso requerirá la adopción práctica de las criptomonedas (no solo el acaparamiento aleatorio de la última moneda meme) y de objetos de valor como las NFT, lo que significa que nuestra riqueza, identidad, datos y medios de vida reales podrían abrirse a un nuevo «Lejano 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 a raíz de Log4Shell

Para los muchos desarrolladores que se vieron sumidos en el caos y se esforzaron por averiguar si había algún caso o dependencia asociada a una versión explotable de la ampliamente utilizada herramienta de registro Log4j, no creo que las vacaciones hubieran sido una época de alegría.

Este ataque de día cero es entre los peores de la historia, con comparaciones realizadas entre Log4Shell y la devastadora vulnerabilidad OpenSSL de Heartbleed que es siguen siendo explotados más de seis años después. Si nos guiamos por este cronograma, nos enfrentaremos a una resaca de Log4Shell durante mucho tiempo en el futuro. Está claro que, a pesar de las lecciones aprendidas con Heartbleed (al menos en lo que respecta a la necesidad de lanzar e implementar los parches lo antes posible), muchas organizaciones simplemente no actúan con la suficiente rapidez para mantenerse protegidas. Según el tamaño de la empresa, la instalación de parches puede resultar increíblemente difícil y burocrática, ya que requiere una documentación e implementación interdepartamentales. Con frecuencia, 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 unos estrictos programas de implementación 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 poner trabas a las cosas y romper algo), pero ir demasiado despacio es ser un blanco fácil.

Al igual que el Ataque SolarWinds cambió las reglas del juego para la cadena de suministro de software, predigo que ocurrirá algo similar a raíz de Log4Shell. Si bien ya existen mandatos y recomendaciones de administración de parches en algunas industrias críticas, la legislación generalizada es otra historia. La seguridad preventiva del software siempre será la mejor oportunidad que tenemos para evitar por completo la aplicación urgente de parches de seguridad, pero las mejores prácticas de seguridad establecen que los parches son una medida prioritaria no negociable. Creo que este será un tema candente y dará lugar a recomendaciones no tan sutiles para aplicar parches con rapidez y frecuencia.

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

La nueva Los 10 mejores de OWASP 2021 tuvo algunas novedades importantes, así como una sorpresa, ya que las vulnerabilidades de inyección cayeron del primer puesto al humilde tercer lugar. Estas nuevas incorporaciones representan una especie de «segunda fase» en el camino de un desarrollador hacia la codificación segura y las mejores prácticas de seguridad y, lamentablemente, la mayoría no está bien preparada para tener un impacto positivo en la reducción del riesgo en este ámbito a menos que cuente con la formación adecuada.

Hace tiempo que sabemos que los desarrolladores deben ser expertos en seguridad si queremos combatir los errores de seguridad más comunes en el código, y las organizaciones responden mejor a la premisa de la prevención impulsada por los desarrolladores. Sin embargo, con Diseño inseguro Al ocupar un lugar entre los 10 mejores de OWASP y al tratarse de una categoría de problemas de seguridad arquitectónica más que de un solo tipo de error de seguridad, los desarrolladores deberán ir más allá de lo básico una vez que los dominen. Los entornos de aprendizaje que abordan la modelización de amenazas (idealmente con el apoyo del equipo de seguridad) disminuyen considerablemente la presión cuando los desarrolladores consiguen mejorar sus habilidades, pero tal y como están las cosas, la mayoría de los ingenieros de software tienen un déficit de conocimiento importante.

Para hacer frente a esto «se necesita mucho esfuerzo», y la organización puede contribuir a crear una cultura de seguridad positiva para los desarrolladores, despertando su curiosidad sin provocar una interrupción importante en su flujo de trabajo.