Los proyectos mal desarrollados e implementados pueden dejar una deuda técnica que hace vulnerable a su empresa frente a los ataques.
Original de IDGNS
Dos de cada tres CISO creen que la deuda técnica, la diferencia entre lo que se necesita en un proyecto y lo que finalmente se implementa, es una causa importante de vulnerabilidad de seguridad, según el informe Voice of the CISO de 2021, patrocinado por Proofpoint.
Según, Jeff Williams, CTO del proveedor de plataformas de seguridad de aplicaciones Contrast Security, la deuda técnica se crea tomando atajos mientras se colocan aspectos cruciales en espera como
- La arquitectura
- La calidad del código
- El rendimiento
- La usabilidad
- Y, en última instancia, la seguridad
“Muchas organizaciones grandes están cargando decenas o cientos de miles de riesgos descubiertos pero no reparados en sus sistemas de gestión de vulnerabilidades. En muchos sectores existe la insidiosa idea de que los esfuerzos de seguridad con fondos insuficientes, además de la gestión de riesgos, son casi tan buenos como realizar el trabajo de seguridad requerido, lo cual es peligrosamente incorrecto”, explica Williams quien asegura que es un enfoque que expone a las empresas y sus socios a un daño significativo.
Reducir el impacto en la seguridad de la deuda técnica comienza por:
- Comprender las diversas formas en que los proyectos mal ejecutados pueden abrir la puerta a intrusos y atacantes;
- Y cómo las vulnerabilidades descubiertas se pueden sellar de manera rápida y segura.
Aquí hay siete formas en que la deuda técnica puede convertirse en un problema para un CISO.
1. Deuda técnica por software dudoso
La deuda técnica es un término sobreutilizado, dice Rahul Telang, profesor de sistemas de información en el Heinz College of Information Systems and Public Policy de la Carnegie Mellon University.
“Básicamente, significa que ha pedido prestado algo para sacar el producto y ahora tiene que pagar la deuda. No es difícil imaginar que, a menos que pague su deuda rápidamente, aumentará el riesgo de seguridad”, explica.
Telang señala que los CISO deben darse cuenta de que cada proyecto de desarrollo de software pasará por etapas en las que el código debe refactorizarse con el tiempo para abordar posibles brechas de seguridad.
Señala que el CISO debe tener una estructura para detectar posibles problemas antes de la implementación, porque es fácil pasar por alto cuando el producto ya se está utilizando.
Ryan Davis, CISO de NS1, desarrollador de tecnologías de gestión de tráfico y DNS, cree que la deuda técnica creada por software conlleva el mayor riesgo de seguridad empresarial.
“Esto incluye elementos que se derivan de fuera de la organización, como lenguajes, bibliotecas de terceros y otros componentes integrados en el software, así como código de origen escrito por desarrolladores internos”, dice.
El software envejece con el tiempo y, periódicamente, se emiten parches para solucionar errores y problemas de seguridad.
Sin embargo, con el tiempo, todo el software llega al final de su vida útil cuando ya no es compatible con el creador.
Desafortunadamente, en algunos casos, puede ser difícil retirar un producto de software actual porque su desarrollador ha abandonado la oferta o ha cerrado el negocio.
Cuando esto sucede, continuar operando el software heredado corre el riesgo de crear una deuda técnica peligrosa, ya que los invasores y atacantes pueden haber descubierto nuevas formas de explotar el software. El resultado puede ser devastador.
“Hemos visto muchos ejemplos del mundo real de cómo la postura de seguridad del software de una sola empresa puede afectar a miles de organizaciones en todo el mundo”, asegura Davis.
2. Gobernanza débil
Una gobernanza sólida es esencial para evitar que la deuda técnica se convierta en un problema de seguridad.
David Chaddock, director de la práctica de ciberseguridad de la empresa consultora de negocios y TI West Monroe, cree que es importante garantizar que se aborde el ciclo de vida completo de un activo durante su diseño e implementación inicial, incluidos los costos operativos a largo plazo y los recursos de soporte necesarios para reducir la posibilidad de que un sistema se convierta repentina o gradualmente en un problema.
“Esto requiere que los equipos de seguridad se involucren desde el principio y se incluyan en el proceso de diseño”, advirtió.
3. Mala alineación estratégica
Un CISO debería trabajar dentro de la empresa para crear una comprensión de la deuda técnica y desarrollar las métricas correctas para administrarla, sugiere Eugene Okwodu, director de soluciones de ciberseguridad en Guidehouse, una empresa global de subcontratación de negocios y TI.
“El CISO también debería incorporar los costos de actualización tecnológica necesarios en su presupuesto”, agrega.
Con frecuencia surge una deuda técnica cuando las estrategias de TI y ciberseguridad chocan.
Okwodu hizo notar que, para garantizar una alineación adecuada y resolver el conflicto, puede ser necesario trabajar con una oficina de gestión de proyectos (PMO) interna o contratar ayuda externa.
4. Descuidar o retrasar la modernización
En algunos casos, pueden pasar años antes de que se manifieste una deuda técnica.
Pero Okwodu recordó que la tecnología obsoleta – tanto de hardware como de software – plantea un gran riesgo de seguridad.
“En algunos casos, la tecnología no solo es imposible de reemplazar y reparar sino que, por lo general, está muy interconectada y es bastante incomprendida por el personal actual, lo que abre el camino a posibles brechas de seguridad”, explicó.
Años y a veces décadas de:
- Soluciones
- Actualizaciones
- Mejoras
- Actividades de fusiones…
… y adquisiciones pueden hacer que la deuda técnica sea especialmente problemática.
“La deuda técnica que requiere una costosa modernización del sistema, especialmente en los sistemas de software, junto con el conocimiento especializado menos común en la fuerza laboral actual, representa un riesgo de seguridad significativo para las empresas en todas las industrias”, afirma el especialista. .
5. No adoptar buenas prácticas de desarrollo
DevSecOps es más que una palabra de moda. La verdad es que se pueden abordar y controlar muchos problemas de seguridad cuando se aplican prácticas de desarrollo sólidas.
“Insista en los principios de DevSecOps adecuados desde el inicio de los proyectos de desarrollo y en los controles que pueden ayudar a visualizar las métricas con respecto a las brechas de seguridad”, recomienda Keatron Evans, investigador principal de seguridad del Infosec Institute, una empresa de capacitación tecnológica.
A medida que los programas crecen, generalmente se vuelven más útiles y más utilizados.
Sin embargo, estos atributos también pueden hacer que las debilidades de seguridad sean más difíciles de corregir o mitigar.
“La misma energía que hace que un fragmento de código crezca y se vuelva productivo, útil y valioso también hace que los problemas de seguridad pasados por alto se vuelvan más devastadores a largo plazo”, asegura Evans.
DevSecOps automatiza la integración de la seguridad en cada fase del ciclo de vida del desarrollo de software, evitando de manera efectiva que, de repente, aparezca una puerta abierta.
6. Deuda técnica por pruebas postergadas
Retener las pruebas de seguridad del software hasta las últimas etapas de desarrollo puede generar vulnerabilidades difíciles, costosas y que lleve mucho tiempo corregir.
“Retrasar las pruebas hasta el final del proceso puede conducir a esfuerzos de reurbanización masivos para abordar los problemas de seguridad, lo que puede significar una pérdida de ganancias y un aumento importante en el tiempo de desarrollo“, advierte Jeremy Dodson, CISO del proveedor de servicios de consultoría DevOps SiguienteLink Labs.
La seguridad debe ser un esfuerzo de colaboración, señala Dodson.
“Un CISO puede ser crucial para crear una cultura de seguridad dentro de su organización, particularmente con el equipo de desarrollo. Un cambio de actitud puede contribuir, por mucho, a la integración de medidas de seguridad en todo el proceso de diseño y desarrollo”, explicó.
7. Complejidad desbocada
Para el director senior de estrategia de plataforma del proveedor de de desarrollo de aplicaciones OutSystems, Barry Goffe, una de las principales causas de la deuda técnica es depender de demasiados lenguajes, herramientas, plataformas y marcos de desarrollo.
“Con la complejidad viene la oportunidad de cometer errores y el aumento de ese riesgo hace que sea más difícil identificar cuándo ocurrieron los errores. Incluso si se identifican problemas, la complejidad hace que sea más difícil solucionar las vulnerabilidades”, subrayó.
La complejidad por sí sola no garantiza las vulnerabilidades de seguridad. Sin embargo, aseguró que, ciertamente, aumenta la probabilidad de que ocurran y aumenta el costo asociado con mantenerlas a raya.
“Dado que la complejidad es una de las principales causas de la deuda técnica, los esfuerzos por estandarizar y simplificar la infraestructura y las herramientas de desarrollo de aplicaciones pueden generar enormes dividendos para minimizar la creación de nueva deuda técnica”, agregó.
Goffe ve la deuda técnica como un factor de riesgo: una suerte de ancla que frena tanto la innovación como la seguridad.
Con las empresas luchando por volver a la normalidad después de la pandemia, ahora es el momento de abordar los obstáculos y los riesgos de seguridad creados por años de construcción rápida en lugar de hacerlo correctamente (o no) en el futuro.
“Cuanto más aborden las empresas la deuda técnica, menos se exponen a riesgos de seguridad y más maximizan su capacidad para innovar”, concluyó Goffe.