Cómo los CISO y CIO creativos pueden innovar y transformar su programa de seguridad

Una versión de este artículo apareció en DevOps.com; ha sido retitulado y actualizado para incluir nueva información.

Aunque los CISO y CIO tienen la difícil tarea de asumir la mayor parte de la responsabilidad en la seguridad del software, especialmente en caso de una vergonzosa filtración de datos, también cuentan con una oportunidad única para ganar relevancia: son los nuevos innovadores y pueden ser muy influyentes si adoptan el enfoque correcto. Todas las organizaciones del planeta, tanto públicas como comerciales, luchan por mantener (y ganar) su cuota de mercado en un mundo que se digitaliza rápidamente. Los clientes esperan una experiencia en línea fluida tanto de los productos pasados como de los futuros, y un enfoque empresarial "digital-first" se está volviendo obligatorio. Al fin y al cabo, si no se cumplen estas expectativas, casi con toda seguridad habrá un competidor listo para aprovechar la oportunidad.

Entonces, ¿qué significa esto para el CISO o CIO moderno? Naturalmente, significa que emplean equipos de desarrolladores, cada uno de los cuales crea línea tras línea el código que forma su producto o servicio digital. La ciberseguridad, aunque ha sido una consideración principal durante muchos años, es un factor de riesgo creciente a medida que más operaciones comerciales se realizan en línea y bajo la mirada de los atacantes. Las implicaciones de una brecha son enormes, pero renunciar a la digitalización no es una opción.

Los CISO y CIO creativos están en una posición privilegiada para seguir forjando el camino de nuestro futuro digital, junto con sus equipos de AppSec y desarrollo. Sin duda, darán forma a la innovación a largo plazo de las empresas, el gobierno y los servicios públicos en línea, pero tienen la pesada responsabilidad de equilibrar los objetivos de rapidez de comercialización, la alta calidad del software y la mitigación de los riesgos de seguridad.

Este equilibrio ha sido, hasta la fecha, inmensamente difícil de lograr. Ha dado lugar a equipos de desarrollo a menudo fragmentados, con un enfoque principal general en la entrega de características y funciones, sin considerar las vulnerabilidades que podrían estar creando en el código que producen tan rápidamente. Los especialistas en AppSec corrigen constantemente los mismos errores, mientras que la amenaza de una brecha por una puerta trasera relativamente simple que se dejó abierta es una amenaza constante.

Si queremos que nuestros datos permanezcan seguros, los CISO y CIO deben ser creativos con la forma en que sus equipos trabajan juntos y forjar una cultura de seguridad positiva y responsabilidad compartida desde arriba hacia abajo. Basta con mirar las consecuencias catastróficas que enfrentó Marriott como resultado de su brecha de 2018: una multa del RGPD de más de 123 millones de dólares, más de 500 millones de registros robados y una reputación de seguridad hecha pedazos. Este desastre ocurrió en gran parte como resultado directo de prácticas de codificación inseguras, con vulnerabilidades de inyección SQL descubiertas ya en 2014 en los servidores de Starwood, una empresa adquirida por Marriott en 2016. Su uso posterior del software claramente no fue supervisado desde una perspectiva de seguridad de aplicaciones. Esto dio a los atacantes malintencionados varios años para acceder y adquirir datos, mientras que otras vulnerabilidades, como las contraseñas débiles, dejaron más agujeros para explotar con el tiempo.

Los CIO y CISO deben considerar muy cuidadosamente el estado de sus propios entornos de seguridad de software. ¿Qué tan consciente de la seguridad es el desarrollador promedio? ¿Qué tan bien están trabajando juntos los equipos de AppSec y desarrollo? No existe una "varita mágica", pero se puede trabajar y mejorar la cultura, la formación y el apoyo. Los equipos de desarrollo pueden transformarse de ser la primera línea de riesgo de brechas de datos en la organización, a convertirse en los superhéroes de la seguridad que detienen el código defectuoso antes de que llegue a producción.

Chequeo de salud de codificación segura: ¿está el suyo en soporte vital?

¿Dónde encaja su propio equipo de desarrollo? He creado esta lista de verificación de codificación segura para ayudar a los CIO y CISO a identificar si sus equipos de desarrollo están realmente equipados para ser campeones de la codificación segura, ayudando a innovar con código más rápido, mejor y más seguro (o, de hecho, si necesita una revisión de su programa de seguridad):

1. ¿Qué tan receptivo es el resto de su equipo directivo? ¿Entienden que la seguridad de red tradicional ya no es suficiente?

En el futuro del software, asegurar la capa de red utilizando medidas de seguridad obsoletas simplemente no es suficiente (y, seamos sinceros, rara vez tiene éxito de todos modos), incluso contra hackers semiprofesionales. Entre muchos informes consistentes, el "Informe de investigaciones de brechas de datos de 2017" de Verizon cita que un asombroso 35 por ciento de las brechas de datos actuales son causadas por vulnerabilidades en aplicaciones web.

La seguridad de las aplicaciones web es tan importante como la seguridad de la red; ignorar esto y no presupuestar e inculcar la capa protectora fundamental y básica de las medidas de AppSec podría dejarlo abierta a una brecha.

2. ¿Se desplaza lo suficiente hacia la izquierda y lo hace con la suficiente antelación?

El enfoque actual de la seguridad de las aplicaciones depende mucho de las herramientas, centrándose en moverse de derecha a izquierda en el ciclo de vida de desarrollo de software (SDLC). Esto, por definición y diseño, reconoce que el proceso es defectuoso y apoya un resultado de detección y reacción. Los equipos de seguridad buscan y detectan vulnerabilidades en código que ya está escrito, reaccionando para corregir el código comprometido en lugar de garantizar que esté libre de errores mientras se crea. Según el Instituto Nacional de Estándares y Tecnología (NIST), es 30 veces más costoso detectar y corregir vulnerabilidades en el código comprometido que prevenirlas mientras se escriben en el IDE. Esto ni siquiera tiene en cuenta los retrasos en la producción, el doble manejo y el tiempo dedicado a remediar los mismos problemas de seguridad conocidos una y otra vez.

Una cultura de seguridad verdaderamente sólida insiste en empezar por la izquierda, inspirando a campeones de seguridad dentro del grupo de desarrolladores, mientras se dota al equipo de desarrollo de las herramientas y la formación adecuadas para crecer y actuar con una mentalidad de codificación segura. Existe un enfoque en el autodesarrollo continuo y en ejercitar sus músculos de resolución de problemas para que puedan ser la primera línea de defensa en su organización, evitando que ocurran vulnerabilidades comunes en primer lugar.

3. ¿Se está esforzando por desarrollar habilidades prácticas de seguridad o simplemente está proporcionando conocimiento unidireccional?

La gran mayoría de las soluciones de formación en seguridad (en línea y CBT) se centran en la creación de conocimientos en lugar de habilidades prácticas que se relacionen directamente con sus trabajos. Para que los desarrolladores prosperen y se comprometan a escribir código seguro, necesitan acceso regular a un aprendizaje contextual y práctico que les anime activamente a seguir formándose y desarrollando habilidades en un entorno real. Necesitan aprender sobre vulnerabilidades identificadas recientemente, con ejemplos de código real, y ser capaces de trabajar en sus lenguajes y marcos preferidos. Esta experiencia de aprendizaje es eficaz para ayudarles a entender cómo localizar, identificar y corregir vulnerabilidades conocidas en el código en el que están trabajando activamente en el curso de sus trabajos.

Aunque hay muchos profesores expertos y mucha información sobre cómo corregir vulnerabilidades de seguridad, hojear libros de texto o ver horas de video no logra captar la atención de muchos desarrolladores creativos que resuelven problemas, y si el flujo constante de brechas de datos sirve de indicación, sigue siendo en gran medida ineficaz para evitar que las vulnerabilidades entren en el código.

4. ¿Está midiendo sus habilidades de codificación segura con métricas en tiempo real?

Un paso fundamental para garantizar que el equipo de desarrollo adopte una mentalidad centrada en la seguridad es recopilar y revisar evidencias. Esto no debe basarse en suposiciones ni conjeturas: los desarrolladores tienen una mentalidad orientada a la seguridad o no la tienen.

Las métricas buscan demostrar al desarrollador y a su organización que su arduo trabajo está dando frutos y que sus habilidades individuales en codificación segura están mejorando. No se puede mejorar lo que no se puede medir. Deben existir evaluaciones pertinentes que ayuden a identificar el progreso de los equipos de desarrollo en tiempo real, así como a comparar sus fortalezas y debilidades en codificación segura para lograr una mejora continua.

Con demasiada frecuencia, la formación en seguridad se convierte en un mero trámite para las organizaciones, sin poner énfasis en garantizar que dicha formación sea efectiva, que los empleados participen en ella o que realmente la retengan.

5. ¿Utilizan sus proveedores externos técnicas sólidas de codificación segura?

Muchas organizaciones deciden subcontratar el desarrollo a agencias externas. Ya sea que operen localmente o en el extranjero, sus capacidades y prácticas generales de codificación segura suelen ser un misterio para el cliente. En el mejor de los casos, la única garantía que recibe la organización es una cláusula contractual que exige que el producto sea "seguro". Muy pocas empresas verifican las habilidades de estas casas de desarrollo de antemano, corriendo el riesgo de recibir software que funciona según lo solicitado, pero que se ha construido sin seguir prácticas de codificación segura. Peor aún, si la empresa compradora desconoce las fallas de seguridad inherentes a la aplicación, corre el riesgo de lanzar software vulnerable al mercado.

El escenario más común es que, cuando los especialistas en seguridad (profesionales difíciles de encontrar y costosos) detectan las vulnerabilidades, usted se enfrenta a retrasos en la fecha de lanzamiento y a posibles disputas contractuales sobre quién debe pagar por corregir esas debilidades. Sin embargo, si actúa con inteligencia desde el principio y evalúa las habilidades de seguridad de los desarrolladores que crearán su próxima aplicación, se ahorrará muchos retrasos, frustraciones y dinero.

6. ¿Conocen sus desarrolladores las debilidades de seguridad más explotadas?

Más del 85 por ciento de las vulnerabilidades explotadas en aplicaciones web se atribuyen a solo 10 debilidades conocidas: el OWASP Top 10. Como mínimo, su formación en seguridad de aplicaciones debe cubrir estos puntos, además de muchos otros tipos de vulnerabilidades. Los desafíos de formación a los que se enfrentan sus desarrolladores deben revisarse y actualizarse periódicamente, incorporando nuevos retos para los marcos de trabajo o tipos de vulnerabilidades emergentes.

La formación precisa basada en escenarios reales de codificación segura debería ser el estándar; el conocimiento general vago simplemente no es efectivo. (¿Se pregunta cómo podrían ser estos escenarios? Eche un vistazo a nuestra serie de blogs Coders Conquer Security; cada publicación incluye un desafío interactivo).

7. ¿Tiene campeones de seguridad internos?

Toda organización con un equipo de desarrollo importante debería invertir en un "campeón de seguridad": alguien que asuma la responsabilidad de mantener un alto estándar de seguridad dentro del equipo. Su propósito es servir como punto de contacto para resolver dudas sobre seguridad y convertirse en el principal defensor de las mejores prácticas en este ámbito.

Son una pieza vital en el rompecabezas de la cultura de seguridad; un buen campeón de seguridad puede mantener el impulso tras una formación intensiva, asegurar que todos los miembros del equipo tengan lo necesario y seguir abogando por el apoyo continuo.

8. ¿Ha invertido en herramientas para facilitar la codificación segura a sus desarrolladores?

Si su organización practica el desarrollo ágil o se enfrenta a actualizaciones frecuentes de sus aplicaciones, automatizar partes de la seguridad es una de las pocas formas de mantener el ritmo frenético y el volumen de trabajo.

Existen herramientas disponibles en cada etapa del ciclo de vida de desarrollo de software (SDLC) que actúan como asesores, guardianes de calidad o herramientas de detección. Además, algunas ejecutan pruebas automatizadas sobre el código, simulando intentos de hackeo una vez que el software está en producción. Todas tienen sus beneficios y desafíos, y ninguna puede garantizar al 100 por ciento la ausencia de amenazas. La medida preventiva número uno es que, cuanto antes detecte la debilidad, más rápido y barato será corregirla con el menor impacto para su negocio.

El siguiente paso para los CISO con visión de futuro

Entonces, ¿cómo le fue a su organización con la lista de verificación anterior?

Aunque los CISO y CIO se ven obligados a desarrollar agresivamente sus capacidades de DevOps y DevSecOps, eso no significa que no haya tiempo para implementar las herramientas y la formación adecuadas. Las habilidades de codificación segura serán un arma para la innovación, no un obstáculo, y prescindir de ellas podría destruir la reputación y los datos de la empresa. Estas habilidades representan capacidades críticas y una solución a largo plazo mucho más económica para reducir vulnerabilidades y mitigar riesgos.

Un CISO brillante e innovador tiene el poder de orquestar una cultura de seguridad saludable desde arriba; asegúrese de que su personal tenga lo necesario para ejecutar las mejores prácticas de seguridad de manera efectiva.

Pieter Danhieux es experto en seguridad y cofundador de Secure Code Warrior.