Icônes SCW
héros bg sans séparateur
Blog

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

Pieter Danhieux
Publié le 23 juillet 2019
Dernière mise à jour le 6 mars 2026

Una versión de este artículo apareció en DevOps.com; se le ha cambiado el título y se ha actualizado para incluir nueva información.

Si bien los CISO y los CIO tienen la posición poco envidiable de asumir la mayor parte de la responsabilidad por la seguridad del software, especialmente en el caso de una embarazosa violación de datos de la empresa, también se les brinda una oportunidad única de aumentar su relevancia: son los nuevos innovadores y pueden tener una gran influencia con el enfoque correcto. Todas las organizaciones del planeta, tanto públicas como comerciales, luchan por conservar (y ganar) su espacio de mercado en un mundo que se digitaliza rápidamente. Los clientes esperan una experiencia en línea perfecta tanto con los productos del pasado como con los del futuro, y cada vez es más obligatorio adoptar un enfoque empresarial que dé prioridad a lo digital. Al fin y al cabo, si no se cumplen estas expectativas, es casi seguro que hay un competidor dispuesto a aprovechar la oportunidad.

Entonces, ¿qué significa eso para el CISO o CIO moderno? Naturalmente, significa que emplean equipos de desarrolladores, cada uno de los cuales crea línea tras línea del código que forma su producto o servicio digital. La ciberseguridad, si bien ha sido una de las principales consideraciones durante muchos años, es un factor de riesgo cada vez mayor, ya que cada vez más operaciones empresariales se llevan a cabo en línea y están en la mira de los atacantes. Las implicaciones de una violación son enormes, pero optar por no participar en la digitalización no es una opción.

Los CISO y CIO creativos se encuentran en una posición privilegiada para seguir forjando el camino de nuestro futuro digital, junto con sus equipos de desarrollo y AppSec. No cabe duda de que darán forma a la innovación a largo plazo de los servicios empresariales, gubernamentales y públicos en línea, pero tienen la gran responsabilidad de equilibrar los objetivos de rapidez de comercialización y una alta calidad del software y mitigar el riesgo de seguridad.

Este equilibrio ha sido, hasta la fecha, inmensamente difícil de lograr. Esto ha llevado a que los equipos de desarrollo estén a menudo fragmentados y se centren principalmente en ofrecer características y funciones, sin tener en cuenta las vulnerabilidades que podrían estar creando en el código que están creando tan rápidamente. Los especialistas de AppSec corrigen constantemente los mismos errores, mientras que la amenaza de que se produzca una violación si se deja abierta una puerta trasera relativamente sencilla es cada vez mayor.

Para que nuestros datos permanezcan seguros, los CISO y los 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 observar las catastróficas consecuencias a las que se enfrentan Marriott como resultado de su infracción en 2018: una multa del RGPD de más de 123 millones de dólares, el robo de más de 500 millones de registros y una reputación de seguridad hecha jirones. Este desastre se produjo en gran parte como resultado directo de prácticas de codificación inseguras, con Las vulnerabilidades de inyección de SQL se descubrieron ya en 2014 en los servidores de Starwoods, una empresa adquirida por Marriott en 2016. Es evidente que su uso posterior del software no fue controlado desde el punto de vista de la seguridad de las aplicaciones. Esto permitió que los atacantes malintencionados tuvieran varios años para acceder a los datos y adquirirlos, mientras que otras vulnerabilidades, como las contraseñas débiles, dejaron más lagunas que aprovechar con el tiempo.

Los CIO y los CISO deben considerar con mucho cuidado el estado de sus propios climas de seguridad de software. ¿Hasta qué punto es consciente de la seguridad el desarrollador promedio? ¿Qué tan bien trabajan juntos los equipos de AppSec y de desarrollo? No existe una solución mágica, pero es posible mejorar la cultura, la formación y el soporte. Equipos de desarrollo poder pasen de ser la primera línea de riesgo de violación de datos de la organización a convertirse en superhéroes de la seguridad que detienen el código incorrecto antes de que entre en producción.

Control de estado de codificación segura: ¿el suyo está en soporte vital?

¿Dónde encaja tu propio equipo de desarrollo? He creado esta lista de verificación de programación segura para ayudar a los directores de TI y a los CISO a identificar si sus equipos de desarrollo están realmente preparados para convertirse en campeones de la codificación segura y ayudar a innovar con un código más rápido, mejor y más seguro (o, de hecho, si necesitan una reforma del programa de seguridad):

1. ¿Qué tan solidario es el resto de su alta dirección? ¿Entienden que la seguridad de red tradicional ya no es suficiente?

En el futuro del software, proteger la capa de red con medidas de seguridad anticuadas simplemente no es suficiente (y, seamos sinceros, de todos modos rara vez tiene éxito) ni siquiera contra piratas informáticos semiprofesionales. Entre los muchos informes consistentes, «Informe de investigaciones sobre violaciones de datos de 2017» de Verizon«cita que un asombroso 35 por ciento de las filtraciones de datos actuales son causadas por vulnerabilidades de aplicaciones web.

La seguridad de las aplicaciones web es tan importante como la seguridad de la red; ignorar esto y no presupuestar ni inculcar la capa de protección básica y fundamental de las medidas de AppSec podría dejarlo realmente expuesto a una violación.

2. ¿Te mueves lo suficientemente a la izquierda y lo haces lo suficientemente pronto?

El enfoque actual de la seguridad de las aplicaciones requiere una gran cantidad de herramientas y se centra en moverse de derecha a izquierda en el ciclo de vida del desarrollo de software (SDLC). Esto, por definición y diseño, reconoce que el proceso es defectuoso y apoya el resultado de la detección y la reacción. Los equipos de seguridad buscan y detectan vulnerabilidades en el código que ya está escrito, reaccionando para corregir el código comprometido en lugar de asegurarse de que esté libre de errores tal como está creado. Según el Instituto Nacional de Estándares y Tecnología (NIST), es Detectar y corregir vulnerabilidades en el código comprometido es 30 veces más caro que evitar que estén escritos en el IDE. Esto ni siquiera tiene en cuenta los retrasos en la producción, la doble gestión y el tiempo dedicado a solucionar los mismos problemas de seguridad conocidos una y otra vez.

Una cultura de seguridad verdaderamente sólida insiste en empezando a la izquierda, inspirando a los defensores de la seguridad de la cohorte de desarrolladores y, al mismo tiempo, proporcionando al equipo de desarrollo las herramientas y la formación adecuadas para crecer y actuar con una mentalidad de codificación segura. Se centran en el autodesarrollo continuo y en desarrollar sus habilidades para resolver problemas, de modo que puedan ser la primera línea de defensa de la organización y evitar que se produzcan las vulnerabilidades más comunes.

3. ¿Se está esforzando por desarrollar habilidades prácticas de seguridad o simplemente está alimentando conocimientos unidireccionales?

La gran mayoría de las soluciones de capacitación en seguridad (en línea y CBT) se centran en desarrollar conocimientos en lugar de habilidades prácticas que se relacionan directamente con sus trabajos. Para que los desarrolladores prosperen y se dediquen a escribir código seguro, necesitan tener acceso regular a un aprendizaje práctico y contextual que los aliente activamente a seguir formándose y desarrollando sus habilidades en un entorno real. Necesitan aprender sobre las vulnerabilidades identificadas recientemente, con ejemplos de código reales, y poder trabajar en sus lenguajes y marcos preferidos. Esta experiencia de aprendizaje es eficaz para ayudarles a entender cómo localizar, identificar y corregir las vulnerabilidades conocidas en el código en el que están trabajando activamente durante el ejercicio de su trabajo.

Si bien hay muchos profesores expertos y mucha información sobre cómo corregir las vulnerabilidades de seguridad, hojear libros de texto o ver horas de vídeo no logra captar la atención de muchos desarrolladores creativos que resuelven problemas y, si el flujo constante de violaciones de datos es un indicio, sigue siendo en gran medida ineficaz a la hora de evitar que las vulnerabilidades ingresen código.

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

Un paso vital para garantizar que un equipo de desarrollo esté creando una mentalidad que dé prioridad a la seguridad es recopilar y revisar las pruebas. Esto no debería ser una suposición o un juego de adivinanzas: los desarrolladores o se preocupan por la seguridad o no lo son.

Metrics busca demostrar al desarrollador y a su organización que su arduo trabajo está dando sus frutos y que sus habilidades individuales de codificación segura están mejorando. No se puede mejorar lo que no se puede medir. Deberían realizarse las evaluaciones pertinentes, que deberían ayudar a identificar el progreso de sus equipos de desarrollo en tiempo real, así como a comparar sus puntos fuertes y débiles en materia de codificación segura para lograr una mejora continua.

Con demasiada frecuencia, la capacitación en seguridad se convierte en un ejercicio que las organizaciones cumplen con los requisitos, sin hacer hincapié en garantizar que esta capacitación haya sido eficaz, participe o incluso se mantenga.

5. ¿Sus proveedores subcontratados utilizan técnicas de codificación sólidas y seguras?

Muchas organizaciones deciden subcontratar el trabajo de desarrollo a agencias de terceros. Ya sea que existan en el extranjero o en el extranjero, sus habilidades y prácticas generales de codificación segura son un misterio relativo para sus clientes. En el mejor de los casos, la única forma de garantía que recibirá una organización en relación con la seguridad es una declaración en el contrato en la que se exija que el producto entregado sea «seguro». Son muy pocas las empresas que toman medidas para verificar por adelantado las aptitudes de estas empresas de desarrollo, por lo que corren el riesgo de recibir un software que funcione según lo previsto, pero que se haya creado sin seguir prácticas de codificación sólidas y seguras. Y lo que es peor, si la empresa compradora no tiene conocimiento de ningún fallo de seguridad inherente en la aplicación, corre el riesgo de que el software vulnerable salga a la luz pública.

El escenario más común es que cualquier vulnerabilidad sea detectada por especialistas en seguridad especializados (personas que son difíciles de encontrar y tienen un coste elevado), y se enfrenta a un retraso en la fecha de puesta en marcha y a posibles discusiones contractuales sobre quién debe pagar para corregir estas debilidades de seguridad. Sin embargo, si eres inteligente desde el principio y evalúas las habilidades de seguridad de las aplicaciones de los desarrolladores que van a crear tu próxima aplicación, te ahorras muchos posibles retrasos, frustraciones y dinero.

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

Más del 85 por ciento de las vulnerabilidades de las aplicaciones web explotadas se atribuyen a solo 10 vulnerabilidades conocidas"la Los 10 mejores de OWASP. Como mínimo, su formación en seguridad de aplicaciones debe cubrir estos, además de muchos más tipos de vulnerabilidades. Los desafíos de capacitación a los que se enfrentan sus desarrolladores deben revisarse y actualizarse de forma regular, con nuevos desafíos para los nuevos marcos de codificación o los nuevos tipos de vulnerabilidades.

El entrenamiento de precisión utilizando escenarios de codificación segura del mundo real debería ser el estándar; un conocimiento general vago simplemente no es efectivo. (¿Se pregunta cómo podrían ser estos escenarios de codificación segura? Eche un vistazo a nuestro Los codificadores conquistan la seguridad serie de blogs; hay un desafío jugable en cada publicación).

7. ¿Tiene campeones de seguridad internos?

Todas las organizaciones con muchos desarrolladores deberían invertir en un campeón de la seguridad, alguien que asuma la responsabilidad de mantener un alto estándar de seguridad dentro del equipo de desarrollo. Su objetivo es ser un punto de contacto de soporte para cualquier persona que tenga preguntas sobre seguridad, así como convertirse en los principales defensores de las mejores prácticas de seguridad.

Son una pieza vital del rompecabezas de la cultura de la seguridad; un gran defensor de la seguridad puede mantener el impulso generado por una formación intensiva, garantizar que todos los miembros del equipo tengan lo que necesitan y seguir abogando por el apoyo.

8. ¿Has invertido en herramientas para que tus desarrolladores faciliten la codificación segura?

Si su organización es una organización en la que se practica el desarrollo ágil o, de hecho, se enfrenta a actualizaciones frecuentes de las aplicaciones creadas por la empresa, la automatización de partes de su seguridad es una de las únicas formas de mantenerse al día con el ritmo y el volumen de trabajo frenéticos.

Hay herramientas disponibles en cada etapa del SDLC que servirán como asesores, guardianes de calidad o herramientas de detección. Además, algunas herramientas realizan pruebas automatizadas sobre el código, simulando un intento de hackeo una vez que el software está en producción. Todas tienen su propio conjunto de ventajas y desafíos, y ninguna puede ofrecer una garantía general del 100 por ciento de que no existen amenazas de seguridad dentro de la aplicación. La medida preventiva número uno que puede emplear es que, cuanto antes pueda detectar la debilidad, más rápido y económico será subsanarla con el menor impacto en su empresa.

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

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

Si bien los CISO y los CIO se ven obligados esencialmente a desarrollar agresivamente sus capacidades empresariales de DevOps y DecSecOps, eso no significa que no haya tiempo para considerar e implementar las herramientas y la capacitación adecuadas en todos los equipos. Las habilidades de programación seguras serán un arma, no un obstáculo, para la innovación, y renunciar a ellas podría significar la destrucción absoluta de 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 las vulnerabilidades y mitigar los riesgos.

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

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

Veuillez consulter la ressource
Veuillez consulter la ressource

Los CISO y CIO creativos e inspiradores tienen el poder de innovar y dar forma a nuestro mundo digital, pero también pueden ser fundamentales para transformar la cultura de seguridad de una organización.

Souhaitez-vous en savoir davantage ?

Directeur général, président et cofondateur

En savoir plus

Secure Code Warrior là pour aider votre organisation à protéger le code tout au long du cycle de vie du développement logiciel et à créer une culture où la cybersécurité est une priorité. Que vous soyez administrateur AppSec, développeur, CISO ou toute autre personne impliquée dans la sécurité, nous pouvons aider votre organisation à réduire les risques associés à un code non sécurisé.

Veuillez réserver une démonstration.
Partager sur :
marques LinkedInSocialLogo x
auteur
Pieter Danhieux
Publié le 23 juillet 2019

Directeur général, président et cofondateur

Pieter Danhieux est un expert en sécurité mondialement reconnu, avec plus de 12 ans d'expérience en tant que consultant en sécurité et 8 ans en tant qu'instructeur principal pour SANS, enseignant des techniques offensives sur la façon de cibler et d'évaluer les organisations, les systèmes et les individus pour les faiblesses de sécurité. En 2016, il a été reconnu comme l'une des personnes les plus cool d'Australie dans le domaine de la technologie (Business Insider), a reçu le prix du professionnel de la cybersécurité de l'année (AISA - Australian Information Security Association) et détient les certifications GSE, CISSP, GCIH, GCFA, GSEC, GPEN, GWAPT, GCIA.

Partager sur :
marques LinkedInSocialLogo x

Una versión de este artículo apareció en DevOps.com; se le ha cambiado el título y se ha actualizado para incluir nueva información.

Si bien los CISO y los CIO tienen la posición poco envidiable de asumir la mayor parte de la responsabilidad por la seguridad del software, especialmente en el caso de una embarazosa violación de datos de la empresa, también se les brinda una oportunidad única de aumentar su relevancia: son los nuevos innovadores y pueden tener una gran influencia con el enfoque correcto. Todas las organizaciones del planeta, tanto públicas como comerciales, luchan por conservar (y ganar) su espacio de mercado en un mundo que se digitaliza rápidamente. Los clientes esperan una experiencia en línea perfecta tanto con los productos del pasado como con los del futuro, y cada vez es más obligatorio adoptar un enfoque empresarial que dé prioridad a lo digital. Al fin y al cabo, si no se cumplen estas expectativas, es casi seguro que hay un competidor dispuesto a aprovechar la oportunidad.

Entonces, ¿qué significa eso para el CISO o CIO moderno? Naturalmente, significa que emplean equipos de desarrolladores, cada uno de los cuales crea línea tras línea del código que forma su producto o servicio digital. La ciberseguridad, si bien ha sido una de las principales consideraciones durante muchos años, es un factor de riesgo cada vez mayor, ya que cada vez más operaciones empresariales se llevan a cabo en línea y están en la mira de los atacantes. Las implicaciones de una violación son enormes, pero optar por no participar en la digitalización no es una opción.

Los CISO y CIO creativos se encuentran en una posición privilegiada para seguir forjando el camino de nuestro futuro digital, junto con sus equipos de desarrollo y AppSec. No cabe duda de que darán forma a la innovación a largo plazo de los servicios empresariales, gubernamentales y públicos en línea, pero tienen la gran responsabilidad de equilibrar los objetivos de rapidez de comercialización y una alta calidad del software y mitigar el riesgo de seguridad.

Este equilibrio ha sido, hasta la fecha, inmensamente difícil de lograr. Esto ha llevado a que los equipos de desarrollo estén a menudo fragmentados y se centren principalmente en ofrecer características y funciones, sin tener en cuenta las vulnerabilidades que podrían estar creando en el código que están creando tan rápidamente. Los especialistas de AppSec corrigen constantemente los mismos errores, mientras que la amenaza de que se produzca una violación si se deja abierta una puerta trasera relativamente sencilla es cada vez mayor.

Para que nuestros datos permanezcan seguros, los CISO y los 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 observar las catastróficas consecuencias a las que se enfrentan Marriott como resultado de su infracción en 2018: una multa del RGPD de más de 123 millones de dólares, el robo de más de 500 millones de registros y una reputación de seguridad hecha jirones. Este desastre se produjo en gran parte como resultado directo de prácticas de codificación inseguras, con Las vulnerabilidades de inyección de SQL se descubrieron ya en 2014 en los servidores de Starwoods, una empresa adquirida por Marriott en 2016. Es evidente que su uso posterior del software no fue controlado desde el punto de vista de la seguridad de las aplicaciones. Esto permitió que los atacantes malintencionados tuvieran varios años para acceder a los datos y adquirirlos, mientras que otras vulnerabilidades, como las contraseñas débiles, dejaron más lagunas que aprovechar con el tiempo.

Los CIO y los CISO deben considerar con mucho cuidado el estado de sus propios climas de seguridad de software. ¿Hasta qué punto es consciente de la seguridad el desarrollador promedio? ¿Qué tan bien trabajan juntos los equipos de AppSec y de desarrollo? No existe una solución mágica, pero es posible mejorar la cultura, la formación y el soporte. Equipos de desarrollo poder pasen de ser la primera línea de riesgo de violación de datos de la organización a convertirse en superhéroes de la seguridad que detienen el código incorrecto antes de que entre en producción.

Control de estado de codificación segura: ¿el suyo está en soporte vital?

¿Dónde encaja tu propio equipo de desarrollo? He creado esta lista de verificación de programación segura para ayudar a los directores de TI y a los CISO a identificar si sus equipos de desarrollo están realmente preparados para convertirse en campeones de la codificación segura y ayudar a innovar con un código más rápido, mejor y más seguro (o, de hecho, si necesitan una reforma del programa de seguridad):

1. ¿Qué tan solidario es el resto de su alta dirección? ¿Entienden que la seguridad de red tradicional ya no es suficiente?

En el futuro del software, proteger la capa de red con medidas de seguridad anticuadas simplemente no es suficiente (y, seamos sinceros, de todos modos rara vez tiene éxito) ni siquiera contra piratas informáticos semiprofesionales. Entre los muchos informes consistentes, «Informe de investigaciones sobre violaciones de datos de 2017» de Verizon«cita que un asombroso 35 por ciento de las filtraciones de datos actuales son causadas por vulnerabilidades de aplicaciones web.

La seguridad de las aplicaciones web es tan importante como la seguridad de la red; ignorar esto y no presupuestar ni inculcar la capa de protección básica y fundamental de las medidas de AppSec podría dejarlo realmente expuesto a una violación.

2. ¿Te mueves lo suficientemente a la izquierda y lo haces lo suficientemente pronto?

El enfoque actual de la seguridad de las aplicaciones requiere una gran cantidad de herramientas y se centra en moverse de derecha a izquierda en el ciclo de vida del desarrollo de software (SDLC). Esto, por definición y diseño, reconoce que el proceso es defectuoso y apoya el resultado de la detección y la reacción. Los equipos de seguridad buscan y detectan vulnerabilidades en el código que ya está escrito, reaccionando para corregir el código comprometido en lugar de asegurarse de que esté libre de errores tal como está creado. Según el Instituto Nacional de Estándares y Tecnología (NIST), es Detectar y corregir vulnerabilidades en el código comprometido es 30 veces más caro que evitar que estén escritos en el IDE. Esto ni siquiera tiene en cuenta los retrasos en la producción, la doble gestión y el tiempo dedicado a solucionar los mismos problemas de seguridad conocidos una y otra vez.

Una cultura de seguridad verdaderamente sólida insiste en empezando a la izquierda, inspirando a los defensores de la seguridad de la cohorte de desarrolladores y, al mismo tiempo, proporcionando al equipo de desarrollo las herramientas y la formación adecuadas para crecer y actuar con una mentalidad de codificación segura. Se centran en el autodesarrollo continuo y en desarrollar sus habilidades para resolver problemas, de modo que puedan ser la primera línea de defensa de la organización y evitar que se produzcan las vulnerabilidades más comunes.

3. ¿Se está esforzando por desarrollar habilidades prácticas de seguridad o simplemente está alimentando conocimientos unidireccionales?

La gran mayoría de las soluciones de capacitación en seguridad (en línea y CBT) se centran en desarrollar conocimientos en lugar de habilidades prácticas que se relacionan directamente con sus trabajos. Para que los desarrolladores prosperen y se dediquen a escribir código seguro, necesitan tener acceso regular a un aprendizaje práctico y contextual que los aliente activamente a seguir formándose y desarrollando sus habilidades en un entorno real. Necesitan aprender sobre las vulnerabilidades identificadas recientemente, con ejemplos de código reales, y poder trabajar en sus lenguajes y marcos preferidos. Esta experiencia de aprendizaje es eficaz para ayudarles a entender cómo localizar, identificar y corregir las vulnerabilidades conocidas en el código en el que están trabajando activamente durante el ejercicio de su trabajo.

Si bien hay muchos profesores expertos y mucha información sobre cómo corregir las vulnerabilidades de seguridad, hojear libros de texto o ver horas de vídeo no logra captar la atención de muchos desarrolladores creativos que resuelven problemas y, si el flujo constante de violaciones de datos es un indicio, sigue siendo en gran medida ineficaz a la hora de evitar que las vulnerabilidades ingresen código.

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

Un paso vital para garantizar que un equipo de desarrollo esté creando una mentalidad que dé prioridad a la seguridad es recopilar y revisar las pruebas. Esto no debería ser una suposición o un juego de adivinanzas: los desarrolladores o se preocupan por la seguridad o no lo son.

Metrics busca demostrar al desarrollador y a su organización que su arduo trabajo está dando sus frutos y que sus habilidades individuales de codificación segura están mejorando. No se puede mejorar lo que no se puede medir. Deberían realizarse las evaluaciones pertinentes, que deberían ayudar a identificar el progreso de sus equipos de desarrollo en tiempo real, así como a comparar sus puntos fuertes y débiles en materia de codificación segura para lograr una mejora continua.

Con demasiada frecuencia, la capacitación en seguridad se convierte en un ejercicio que las organizaciones cumplen con los requisitos, sin hacer hincapié en garantizar que esta capacitación haya sido eficaz, participe o incluso se mantenga.

5. ¿Sus proveedores subcontratados utilizan técnicas de codificación sólidas y seguras?

Muchas organizaciones deciden subcontratar el trabajo de desarrollo a agencias de terceros. Ya sea que existan en el extranjero o en el extranjero, sus habilidades y prácticas generales de codificación segura son un misterio relativo para sus clientes. En el mejor de los casos, la única forma de garantía que recibirá una organización en relación con la seguridad es una declaración en el contrato en la que se exija que el producto entregado sea «seguro». Son muy pocas las empresas que toman medidas para verificar por adelantado las aptitudes de estas empresas de desarrollo, por lo que corren el riesgo de recibir un software que funcione según lo previsto, pero que se haya creado sin seguir prácticas de codificación sólidas y seguras. Y lo que es peor, si la empresa compradora no tiene conocimiento de ningún fallo de seguridad inherente en la aplicación, corre el riesgo de que el software vulnerable salga a la luz pública.

El escenario más común es que cualquier vulnerabilidad sea detectada por especialistas en seguridad especializados (personas que son difíciles de encontrar y tienen un coste elevado), y se enfrenta a un retraso en la fecha de puesta en marcha y a posibles discusiones contractuales sobre quién debe pagar para corregir estas debilidades de seguridad. Sin embargo, si eres inteligente desde el principio y evalúas las habilidades de seguridad de las aplicaciones de los desarrolladores que van a crear tu próxima aplicación, te ahorras muchos posibles retrasos, frustraciones y dinero.

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

Más del 85 por ciento de las vulnerabilidades de las aplicaciones web explotadas se atribuyen a solo 10 vulnerabilidades conocidas"la Los 10 mejores de OWASP. Como mínimo, su formación en seguridad de aplicaciones debe cubrir estos, además de muchos más tipos de vulnerabilidades. Los desafíos de capacitación a los que se enfrentan sus desarrolladores deben revisarse y actualizarse de forma regular, con nuevos desafíos para los nuevos marcos de codificación o los nuevos tipos de vulnerabilidades.

El entrenamiento de precisión utilizando escenarios de codificación segura del mundo real debería ser el estándar; un conocimiento general vago simplemente no es efectivo. (¿Se pregunta cómo podrían ser estos escenarios de codificación segura? Eche un vistazo a nuestro Los codificadores conquistan la seguridad serie de blogs; hay un desafío jugable en cada publicación).

7. ¿Tiene campeones de seguridad internos?

Todas las organizaciones con muchos desarrolladores deberían invertir en un campeón de la seguridad, alguien que asuma la responsabilidad de mantener un alto estándar de seguridad dentro del equipo de desarrollo. Su objetivo es ser un punto de contacto de soporte para cualquier persona que tenga preguntas sobre seguridad, así como convertirse en los principales defensores de las mejores prácticas de seguridad.

Son una pieza vital del rompecabezas de la cultura de la seguridad; un gran defensor de la seguridad puede mantener el impulso generado por una formación intensiva, garantizar que todos los miembros del equipo tengan lo que necesitan y seguir abogando por el apoyo.

8. ¿Has invertido en herramientas para que tus desarrolladores faciliten la codificación segura?

Si su organización es una organización en la que se practica el desarrollo ágil o, de hecho, se enfrenta a actualizaciones frecuentes de las aplicaciones creadas por la empresa, la automatización de partes de su seguridad es una de las únicas formas de mantenerse al día con el ritmo y el volumen de trabajo frenéticos.

Hay herramientas disponibles en cada etapa del SDLC que servirán como asesores, guardianes de calidad o herramientas de detección. Además, algunas herramientas realizan pruebas automatizadas sobre el código, simulando un intento de hackeo una vez que el software está en producción. Todas tienen su propio conjunto de ventajas y desafíos, y ninguna puede ofrecer una garantía general del 100 por ciento de que no existen amenazas de seguridad dentro de la aplicación. La medida preventiva número uno que puede emplear es que, cuanto antes pueda detectar la debilidad, más rápido y económico será subsanarla con el menor impacto en su empresa.

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

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

Si bien los CISO y los CIO se ven obligados esencialmente a desarrollar agresivamente sus capacidades empresariales de DevOps y DecSecOps, eso no significa que no haya tiempo para considerar e implementar las herramientas y la capacitación adecuadas en todos los equipos. Las habilidades de programación seguras serán un arma, no un obstáculo, para la innovación, y renunciar a ellas podría significar la destrucción absoluta de 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 las vulnerabilidades y mitigar los riesgos.

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

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

Veuillez consulter la ressource
Veuillez consulter la ressource

Veuillez remplir le formulaire suivant pour télécharger le rapport.

Nous souhaiterions obtenir votre autorisation pour vous envoyer des informations sur nos produits ou sur des sujets liés au codage sécurisé. Nous traiterons toujours vos données personnelles avec le plus grand soin et ne les vendrons jamais à d'autres entreprises à des fins de marketing.

Envoyer
icône de réussite scw
icône d'erreur scw
Pour envoyer le formulaire, veuillez activer les cookies « d'analyse ». N'hésitez pas à les désactiver à nouveau une fois que vous avez terminé.

Una versión de este artículo apareció en DevOps.com; se le ha cambiado el título y se ha actualizado para incluir nueva información.

Si bien los CISO y los CIO tienen la posición poco envidiable de asumir la mayor parte de la responsabilidad por la seguridad del software, especialmente en el caso de una embarazosa violación de datos de la empresa, también se les brinda una oportunidad única de aumentar su relevancia: son los nuevos innovadores y pueden tener una gran influencia con el enfoque correcto. Todas las organizaciones del planeta, tanto públicas como comerciales, luchan por conservar (y ganar) su espacio de mercado en un mundo que se digitaliza rápidamente. Los clientes esperan una experiencia en línea perfecta tanto con los productos del pasado como con los del futuro, y cada vez es más obligatorio adoptar un enfoque empresarial que dé prioridad a lo digital. Al fin y al cabo, si no se cumplen estas expectativas, es casi seguro que hay un competidor dispuesto a aprovechar la oportunidad.

Entonces, ¿qué significa eso para el CISO o CIO moderno? Naturalmente, significa que emplean equipos de desarrolladores, cada uno de los cuales crea línea tras línea del código que forma su producto o servicio digital. La ciberseguridad, si bien ha sido una de las principales consideraciones durante muchos años, es un factor de riesgo cada vez mayor, ya que cada vez más operaciones empresariales se llevan a cabo en línea y están en la mira de los atacantes. Las implicaciones de una violación son enormes, pero optar por no participar en la digitalización no es una opción.

Los CISO y CIO creativos se encuentran en una posición privilegiada para seguir forjando el camino de nuestro futuro digital, junto con sus equipos de desarrollo y AppSec. No cabe duda de que darán forma a la innovación a largo plazo de los servicios empresariales, gubernamentales y públicos en línea, pero tienen la gran responsabilidad de equilibrar los objetivos de rapidez de comercialización y una alta calidad del software y mitigar el riesgo de seguridad.

Este equilibrio ha sido, hasta la fecha, inmensamente difícil de lograr. Esto ha llevado a que los equipos de desarrollo estén a menudo fragmentados y se centren principalmente en ofrecer características y funciones, sin tener en cuenta las vulnerabilidades que podrían estar creando en el código que están creando tan rápidamente. Los especialistas de AppSec corrigen constantemente los mismos errores, mientras que la amenaza de que se produzca una violación si se deja abierta una puerta trasera relativamente sencilla es cada vez mayor.

Para que nuestros datos permanezcan seguros, los CISO y los 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 observar las catastróficas consecuencias a las que se enfrentan Marriott como resultado de su infracción en 2018: una multa del RGPD de más de 123 millones de dólares, el robo de más de 500 millones de registros y una reputación de seguridad hecha jirones. Este desastre se produjo en gran parte como resultado directo de prácticas de codificación inseguras, con Las vulnerabilidades de inyección de SQL se descubrieron ya en 2014 en los servidores de Starwoods, una empresa adquirida por Marriott en 2016. Es evidente que su uso posterior del software no fue controlado desde el punto de vista de la seguridad de las aplicaciones. Esto permitió que los atacantes malintencionados tuvieran varios años para acceder a los datos y adquirirlos, mientras que otras vulnerabilidades, como las contraseñas débiles, dejaron más lagunas que aprovechar con el tiempo.

Los CIO y los CISO deben considerar con mucho cuidado el estado de sus propios climas de seguridad de software. ¿Hasta qué punto es consciente de la seguridad el desarrollador promedio? ¿Qué tan bien trabajan juntos los equipos de AppSec y de desarrollo? No existe una solución mágica, pero es posible mejorar la cultura, la formación y el soporte. Equipos de desarrollo poder pasen de ser la primera línea de riesgo de violación de datos de la organización a convertirse en superhéroes de la seguridad que detienen el código incorrecto antes de que entre en producción.

Control de estado de codificación segura: ¿el suyo está en soporte vital?

¿Dónde encaja tu propio equipo de desarrollo? He creado esta lista de verificación de programación segura para ayudar a los directores de TI y a los CISO a identificar si sus equipos de desarrollo están realmente preparados para convertirse en campeones de la codificación segura y ayudar a innovar con un código más rápido, mejor y más seguro (o, de hecho, si necesitan una reforma del programa de seguridad):

1. ¿Qué tan solidario es el resto de su alta dirección? ¿Entienden que la seguridad de red tradicional ya no es suficiente?

En el futuro del software, proteger la capa de red con medidas de seguridad anticuadas simplemente no es suficiente (y, seamos sinceros, de todos modos rara vez tiene éxito) ni siquiera contra piratas informáticos semiprofesionales. Entre los muchos informes consistentes, «Informe de investigaciones sobre violaciones de datos de 2017» de Verizon«cita que un asombroso 35 por ciento de las filtraciones de datos actuales son causadas por vulnerabilidades de aplicaciones web.

La seguridad de las aplicaciones web es tan importante como la seguridad de la red; ignorar esto y no presupuestar ni inculcar la capa de protección básica y fundamental de las medidas de AppSec podría dejarlo realmente expuesto a una violación.

2. ¿Te mueves lo suficientemente a la izquierda y lo haces lo suficientemente pronto?

El enfoque actual de la seguridad de las aplicaciones requiere una gran cantidad de herramientas y se centra en moverse de derecha a izquierda en el ciclo de vida del desarrollo de software (SDLC). Esto, por definición y diseño, reconoce que el proceso es defectuoso y apoya el resultado de la detección y la reacción. Los equipos de seguridad buscan y detectan vulnerabilidades en el código que ya está escrito, reaccionando para corregir el código comprometido en lugar de asegurarse de que esté libre de errores tal como está creado. Según el Instituto Nacional de Estándares y Tecnología (NIST), es Detectar y corregir vulnerabilidades en el código comprometido es 30 veces más caro que evitar que estén escritos en el IDE. Esto ni siquiera tiene en cuenta los retrasos en la producción, la doble gestión y el tiempo dedicado a solucionar los mismos problemas de seguridad conocidos una y otra vez.

Una cultura de seguridad verdaderamente sólida insiste en empezando a la izquierda, inspirando a los defensores de la seguridad de la cohorte de desarrolladores y, al mismo tiempo, proporcionando al equipo de desarrollo las herramientas y la formación adecuadas para crecer y actuar con una mentalidad de codificación segura. Se centran en el autodesarrollo continuo y en desarrollar sus habilidades para resolver problemas, de modo que puedan ser la primera línea de defensa de la organización y evitar que se produzcan las vulnerabilidades más comunes.

3. ¿Se está esforzando por desarrollar habilidades prácticas de seguridad o simplemente está alimentando conocimientos unidireccionales?

La gran mayoría de las soluciones de capacitación en seguridad (en línea y CBT) se centran en desarrollar conocimientos en lugar de habilidades prácticas que se relacionan directamente con sus trabajos. Para que los desarrolladores prosperen y se dediquen a escribir código seguro, necesitan tener acceso regular a un aprendizaje práctico y contextual que los aliente activamente a seguir formándose y desarrollando sus habilidades en un entorno real. Necesitan aprender sobre las vulnerabilidades identificadas recientemente, con ejemplos de código reales, y poder trabajar en sus lenguajes y marcos preferidos. Esta experiencia de aprendizaje es eficaz para ayudarles a entender cómo localizar, identificar y corregir las vulnerabilidades conocidas en el código en el que están trabajando activamente durante el ejercicio de su trabajo.

Si bien hay muchos profesores expertos y mucha información sobre cómo corregir las vulnerabilidades de seguridad, hojear libros de texto o ver horas de vídeo no logra captar la atención de muchos desarrolladores creativos que resuelven problemas y, si el flujo constante de violaciones de datos es un indicio, sigue siendo en gran medida ineficaz a la hora de evitar que las vulnerabilidades ingresen código.

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

Un paso vital para garantizar que un equipo de desarrollo esté creando una mentalidad que dé prioridad a la seguridad es recopilar y revisar las pruebas. Esto no debería ser una suposición o un juego de adivinanzas: los desarrolladores o se preocupan por la seguridad o no lo son.

Metrics busca demostrar al desarrollador y a su organización que su arduo trabajo está dando sus frutos y que sus habilidades individuales de codificación segura están mejorando. No se puede mejorar lo que no se puede medir. Deberían realizarse las evaluaciones pertinentes, que deberían ayudar a identificar el progreso de sus equipos de desarrollo en tiempo real, así como a comparar sus puntos fuertes y débiles en materia de codificación segura para lograr una mejora continua.

Con demasiada frecuencia, la capacitación en seguridad se convierte en un ejercicio que las organizaciones cumplen con los requisitos, sin hacer hincapié en garantizar que esta capacitación haya sido eficaz, participe o incluso se mantenga.

5. ¿Sus proveedores subcontratados utilizan técnicas de codificación sólidas y seguras?

Muchas organizaciones deciden subcontratar el trabajo de desarrollo a agencias de terceros. Ya sea que existan en el extranjero o en el extranjero, sus habilidades y prácticas generales de codificación segura son un misterio relativo para sus clientes. En el mejor de los casos, la única forma de garantía que recibirá una organización en relación con la seguridad es una declaración en el contrato en la que se exija que el producto entregado sea «seguro». Son muy pocas las empresas que toman medidas para verificar por adelantado las aptitudes de estas empresas de desarrollo, por lo que corren el riesgo de recibir un software que funcione según lo previsto, pero que se haya creado sin seguir prácticas de codificación sólidas y seguras. Y lo que es peor, si la empresa compradora no tiene conocimiento de ningún fallo de seguridad inherente en la aplicación, corre el riesgo de que el software vulnerable salga a la luz pública.

El escenario más común es que cualquier vulnerabilidad sea detectada por especialistas en seguridad especializados (personas que son difíciles de encontrar y tienen un coste elevado), y se enfrenta a un retraso en la fecha de puesta en marcha y a posibles discusiones contractuales sobre quién debe pagar para corregir estas debilidades de seguridad. Sin embargo, si eres inteligente desde el principio y evalúas las habilidades de seguridad de las aplicaciones de los desarrolladores que van a crear tu próxima aplicación, te ahorras muchos posibles retrasos, frustraciones y dinero.

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

Más del 85 por ciento de las vulnerabilidades de las aplicaciones web explotadas se atribuyen a solo 10 vulnerabilidades conocidas"la Los 10 mejores de OWASP. Como mínimo, su formación en seguridad de aplicaciones debe cubrir estos, además de muchos más tipos de vulnerabilidades. Los desafíos de capacitación a los que se enfrentan sus desarrolladores deben revisarse y actualizarse de forma regular, con nuevos desafíos para los nuevos marcos de codificación o los nuevos tipos de vulnerabilidades.

El entrenamiento de precisión utilizando escenarios de codificación segura del mundo real debería ser el estándar; un conocimiento general vago simplemente no es efectivo. (¿Se pregunta cómo podrían ser estos escenarios de codificación segura? Eche un vistazo a nuestro Los codificadores conquistan la seguridad serie de blogs; hay un desafío jugable en cada publicación).

7. ¿Tiene campeones de seguridad internos?

Todas las organizaciones con muchos desarrolladores deberían invertir en un campeón de la seguridad, alguien que asuma la responsabilidad de mantener un alto estándar de seguridad dentro del equipo de desarrollo. Su objetivo es ser un punto de contacto de soporte para cualquier persona que tenga preguntas sobre seguridad, así como convertirse en los principales defensores de las mejores prácticas de seguridad.

Son una pieza vital del rompecabezas de la cultura de la seguridad; un gran defensor de la seguridad puede mantener el impulso generado por una formación intensiva, garantizar que todos los miembros del equipo tengan lo que necesitan y seguir abogando por el apoyo.

8. ¿Has invertido en herramientas para que tus desarrolladores faciliten la codificación segura?

Si su organización es una organización en la que se practica el desarrollo ágil o, de hecho, se enfrenta a actualizaciones frecuentes de las aplicaciones creadas por la empresa, la automatización de partes de su seguridad es una de las únicas formas de mantenerse al día con el ritmo y el volumen de trabajo frenéticos.

Hay herramientas disponibles en cada etapa del SDLC que servirán como asesores, guardianes de calidad o herramientas de detección. Además, algunas herramientas realizan pruebas automatizadas sobre el código, simulando un intento de hackeo una vez que el software está en producción. Todas tienen su propio conjunto de ventajas y desafíos, y ninguna puede ofrecer una garantía general del 100 por ciento de que no existen amenazas de seguridad dentro de la aplicación. La medida preventiva número uno que puede emplear es que, cuanto antes pueda detectar la debilidad, más rápido y económico será subsanarla con el menor impacto en su empresa.

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

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

Si bien los CISO y los CIO se ven obligados esencialmente a desarrollar agresivamente sus capacidades empresariales de DevOps y DecSecOps, eso no significa que no haya tiempo para considerar e implementar las herramientas y la capacitación adecuadas en todos los equipos. Las habilidades de programación seguras serán un arma, no un obstáculo, para la innovación, y renunciar a ellas podría significar la destrucción absoluta de 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 las vulnerabilidades y mitigar los riesgos.

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

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

Veuillez consulter le webinaire
Commencer
En savoir plus

Veuillez cliquer sur le lien ci-dessous et télécharger le PDF de cette ressource.

Secure Code Warrior là pour aider votre organisation à protéger le code tout au long du cycle de vie du développement logiciel et à créer une culture où la cybersécurité est une priorité. Que vous soyez administrateur AppSec, développeur, CISO ou toute autre personne impliquée dans la sécurité, nous pouvons aider votre organisation à réduire les risques associés à un code non sécurisé.

Veuillez consulter le rapportVeuillez réserver une démonstration.
Télécharger le PDF
Veuillez consulter la ressource
Partager sur :
marques LinkedInSocialLogo x
Souhaitez-vous en savoir davantage ?

Partager sur :
marques LinkedInSocialLogo x
auteur
Pieter Danhieux
Publié le 23 juillet 2019

Directeur général, président et cofondateur

Pieter Danhieux est un expert en sécurité mondialement reconnu, avec plus de 12 ans d'expérience en tant que consultant en sécurité et 8 ans en tant qu'instructeur principal pour SANS, enseignant des techniques offensives sur la façon de cibler et d'évaluer les organisations, les systèmes et les individus pour les faiblesses de sécurité. En 2016, il a été reconnu comme l'une des personnes les plus cool d'Australie dans le domaine de la technologie (Business Insider), a reçu le prix du professionnel de la cybersécurité de l'année (AISA - Australian Information Security Association) et détient les certifications GSE, CISSP, GCIH, GCFA, GSEC, GPEN, GWAPT, GCIA.

Partager sur :
marques LinkedInSocialLogo x

Una versión de este artículo apareció en DevOps.com; se le ha cambiado el título y se ha actualizado para incluir nueva información.

Si bien los CISO y los CIO tienen la posición poco envidiable de asumir la mayor parte de la responsabilidad por la seguridad del software, especialmente en el caso de una embarazosa violación de datos de la empresa, también se les brinda una oportunidad única de aumentar su relevancia: son los nuevos innovadores y pueden tener una gran influencia con el enfoque correcto. Todas las organizaciones del planeta, tanto públicas como comerciales, luchan por conservar (y ganar) su espacio de mercado en un mundo que se digitaliza rápidamente. Los clientes esperan una experiencia en línea perfecta tanto con los productos del pasado como con los del futuro, y cada vez es más obligatorio adoptar un enfoque empresarial que dé prioridad a lo digital. Al fin y al cabo, si no se cumplen estas expectativas, es casi seguro que hay un competidor dispuesto a aprovechar la oportunidad.

Entonces, ¿qué significa eso para el CISO o CIO moderno? Naturalmente, significa que emplean equipos de desarrolladores, cada uno de los cuales crea línea tras línea del código que forma su producto o servicio digital. La ciberseguridad, si bien ha sido una de las principales consideraciones durante muchos años, es un factor de riesgo cada vez mayor, ya que cada vez más operaciones empresariales se llevan a cabo en línea y están en la mira de los atacantes. Las implicaciones de una violación son enormes, pero optar por no participar en la digitalización no es una opción.

Los CISO y CIO creativos se encuentran en una posición privilegiada para seguir forjando el camino de nuestro futuro digital, junto con sus equipos de desarrollo y AppSec. No cabe duda de que darán forma a la innovación a largo plazo de los servicios empresariales, gubernamentales y públicos en línea, pero tienen la gran responsabilidad de equilibrar los objetivos de rapidez de comercialización y una alta calidad del software y mitigar el riesgo de seguridad.

Este equilibrio ha sido, hasta la fecha, inmensamente difícil de lograr. Esto ha llevado a que los equipos de desarrollo estén a menudo fragmentados y se centren principalmente en ofrecer características y funciones, sin tener en cuenta las vulnerabilidades que podrían estar creando en el código que están creando tan rápidamente. Los especialistas de AppSec corrigen constantemente los mismos errores, mientras que la amenaza de que se produzca una violación si se deja abierta una puerta trasera relativamente sencilla es cada vez mayor.

Para que nuestros datos permanezcan seguros, los CISO y los 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 observar las catastróficas consecuencias a las que se enfrentan Marriott como resultado de su infracción en 2018: una multa del RGPD de más de 123 millones de dólares, el robo de más de 500 millones de registros y una reputación de seguridad hecha jirones. Este desastre se produjo en gran parte como resultado directo de prácticas de codificación inseguras, con Las vulnerabilidades de inyección de SQL se descubrieron ya en 2014 en los servidores de Starwoods, una empresa adquirida por Marriott en 2016. Es evidente que su uso posterior del software no fue controlado desde el punto de vista de la seguridad de las aplicaciones. Esto permitió que los atacantes malintencionados tuvieran varios años para acceder a los datos y adquirirlos, mientras que otras vulnerabilidades, como las contraseñas débiles, dejaron más lagunas que aprovechar con el tiempo.

Los CIO y los CISO deben considerar con mucho cuidado el estado de sus propios climas de seguridad de software. ¿Hasta qué punto es consciente de la seguridad el desarrollador promedio? ¿Qué tan bien trabajan juntos los equipos de AppSec y de desarrollo? No existe una solución mágica, pero es posible mejorar la cultura, la formación y el soporte. Equipos de desarrollo poder pasen de ser la primera línea de riesgo de violación de datos de la organización a convertirse en superhéroes de la seguridad que detienen el código incorrecto antes de que entre en producción.

Control de estado de codificación segura: ¿el suyo está en soporte vital?

¿Dónde encaja tu propio equipo de desarrollo? He creado esta lista de verificación de programación segura para ayudar a los directores de TI y a los CISO a identificar si sus equipos de desarrollo están realmente preparados para convertirse en campeones de la codificación segura y ayudar a innovar con un código más rápido, mejor y más seguro (o, de hecho, si necesitan una reforma del programa de seguridad):

1. ¿Qué tan solidario es el resto de su alta dirección? ¿Entienden que la seguridad de red tradicional ya no es suficiente?

En el futuro del software, proteger la capa de red con medidas de seguridad anticuadas simplemente no es suficiente (y, seamos sinceros, de todos modos rara vez tiene éxito) ni siquiera contra piratas informáticos semiprofesionales. Entre los muchos informes consistentes, «Informe de investigaciones sobre violaciones de datos de 2017» de Verizon«cita que un asombroso 35 por ciento de las filtraciones de datos actuales son causadas por vulnerabilidades de aplicaciones web.

La seguridad de las aplicaciones web es tan importante como la seguridad de la red; ignorar esto y no presupuestar ni inculcar la capa de protección básica y fundamental de las medidas de AppSec podría dejarlo realmente expuesto a una violación.

2. ¿Te mueves lo suficientemente a la izquierda y lo haces lo suficientemente pronto?

El enfoque actual de la seguridad de las aplicaciones requiere una gran cantidad de herramientas y se centra en moverse de derecha a izquierda en el ciclo de vida del desarrollo de software (SDLC). Esto, por definición y diseño, reconoce que el proceso es defectuoso y apoya el resultado de la detección y la reacción. Los equipos de seguridad buscan y detectan vulnerabilidades en el código que ya está escrito, reaccionando para corregir el código comprometido en lugar de asegurarse de que esté libre de errores tal como está creado. Según el Instituto Nacional de Estándares y Tecnología (NIST), es Detectar y corregir vulnerabilidades en el código comprometido es 30 veces más caro que evitar que estén escritos en el IDE. Esto ni siquiera tiene en cuenta los retrasos en la producción, la doble gestión y el tiempo dedicado a solucionar los mismos problemas de seguridad conocidos una y otra vez.

Una cultura de seguridad verdaderamente sólida insiste en empezando a la izquierda, inspirando a los defensores de la seguridad de la cohorte de desarrolladores y, al mismo tiempo, proporcionando al equipo de desarrollo las herramientas y la formación adecuadas para crecer y actuar con una mentalidad de codificación segura. Se centran en el autodesarrollo continuo y en desarrollar sus habilidades para resolver problemas, de modo que puedan ser la primera línea de defensa de la organización y evitar que se produzcan las vulnerabilidades más comunes.

3. ¿Se está esforzando por desarrollar habilidades prácticas de seguridad o simplemente está alimentando conocimientos unidireccionales?

La gran mayoría de las soluciones de capacitación en seguridad (en línea y CBT) se centran en desarrollar conocimientos en lugar de habilidades prácticas que se relacionan directamente con sus trabajos. Para que los desarrolladores prosperen y se dediquen a escribir código seguro, necesitan tener acceso regular a un aprendizaje práctico y contextual que los aliente activamente a seguir formándose y desarrollando sus habilidades en un entorno real. Necesitan aprender sobre las vulnerabilidades identificadas recientemente, con ejemplos de código reales, y poder trabajar en sus lenguajes y marcos preferidos. Esta experiencia de aprendizaje es eficaz para ayudarles a entender cómo localizar, identificar y corregir las vulnerabilidades conocidas en el código en el que están trabajando activamente durante el ejercicio de su trabajo.

Si bien hay muchos profesores expertos y mucha información sobre cómo corregir las vulnerabilidades de seguridad, hojear libros de texto o ver horas de vídeo no logra captar la atención de muchos desarrolladores creativos que resuelven problemas y, si el flujo constante de violaciones de datos es un indicio, sigue siendo en gran medida ineficaz a la hora de evitar que las vulnerabilidades ingresen código.

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

Un paso vital para garantizar que un equipo de desarrollo esté creando una mentalidad que dé prioridad a la seguridad es recopilar y revisar las pruebas. Esto no debería ser una suposición o un juego de adivinanzas: los desarrolladores o se preocupan por la seguridad o no lo son.

Metrics busca demostrar al desarrollador y a su organización que su arduo trabajo está dando sus frutos y que sus habilidades individuales de codificación segura están mejorando. No se puede mejorar lo que no se puede medir. Deberían realizarse las evaluaciones pertinentes, que deberían ayudar a identificar el progreso de sus equipos de desarrollo en tiempo real, así como a comparar sus puntos fuertes y débiles en materia de codificación segura para lograr una mejora continua.

Con demasiada frecuencia, la capacitación en seguridad se convierte en un ejercicio que las organizaciones cumplen con los requisitos, sin hacer hincapié en garantizar que esta capacitación haya sido eficaz, participe o incluso se mantenga.

5. ¿Sus proveedores subcontratados utilizan técnicas de codificación sólidas y seguras?

Muchas organizaciones deciden subcontratar el trabajo de desarrollo a agencias de terceros. Ya sea que existan en el extranjero o en el extranjero, sus habilidades y prácticas generales de codificación segura son un misterio relativo para sus clientes. En el mejor de los casos, la única forma de garantía que recibirá una organización en relación con la seguridad es una declaración en el contrato en la que se exija que el producto entregado sea «seguro». Son muy pocas las empresas que toman medidas para verificar por adelantado las aptitudes de estas empresas de desarrollo, por lo que corren el riesgo de recibir un software que funcione según lo previsto, pero que se haya creado sin seguir prácticas de codificación sólidas y seguras. Y lo que es peor, si la empresa compradora no tiene conocimiento de ningún fallo de seguridad inherente en la aplicación, corre el riesgo de que el software vulnerable salga a la luz pública.

El escenario más común es que cualquier vulnerabilidad sea detectada por especialistas en seguridad especializados (personas que son difíciles de encontrar y tienen un coste elevado), y se enfrenta a un retraso en la fecha de puesta en marcha y a posibles discusiones contractuales sobre quién debe pagar para corregir estas debilidades de seguridad. Sin embargo, si eres inteligente desde el principio y evalúas las habilidades de seguridad de las aplicaciones de los desarrolladores que van a crear tu próxima aplicación, te ahorras muchos posibles retrasos, frustraciones y dinero.

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

Más del 85 por ciento de las vulnerabilidades de las aplicaciones web explotadas se atribuyen a solo 10 vulnerabilidades conocidas"la Los 10 mejores de OWASP. Como mínimo, su formación en seguridad de aplicaciones debe cubrir estos, además de muchos más tipos de vulnerabilidades. Los desafíos de capacitación a los que se enfrentan sus desarrolladores deben revisarse y actualizarse de forma regular, con nuevos desafíos para los nuevos marcos de codificación o los nuevos tipos de vulnerabilidades.

El entrenamiento de precisión utilizando escenarios de codificación segura del mundo real debería ser el estándar; un conocimiento general vago simplemente no es efectivo. (¿Se pregunta cómo podrían ser estos escenarios de codificación segura? Eche un vistazo a nuestro Los codificadores conquistan la seguridad serie de blogs; hay un desafío jugable en cada publicación).

7. ¿Tiene campeones de seguridad internos?

Todas las organizaciones con muchos desarrolladores deberían invertir en un campeón de la seguridad, alguien que asuma la responsabilidad de mantener un alto estándar de seguridad dentro del equipo de desarrollo. Su objetivo es ser un punto de contacto de soporte para cualquier persona que tenga preguntas sobre seguridad, así como convertirse en los principales defensores de las mejores prácticas de seguridad.

Son una pieza vital del rompecabezas de la cultura de la seguridad; un gran defensor de la seguridad puede mantener el impulso generado por una formación intensiva, garantizar que todos los miembros del equipo tengan lo que necesitan y seguir abogando por el apoyo.

8. ¿Has invertido en herramientas para que tus desarrolladores faciliten la codificación segura?

Si su organización es una organización en la que se practica el desarrollo ágil o, de hecho, se enfrenta a actualizaciones frecuentes de las aplicaciones creadas por la empresa, la automatización de partes de su seguridad es una de las únicas formas de mantenerse al día con el ritmo y el volumen de trabajo frenéticos.

Hay herramientas disponibles en cada etapa del SDLC que servirán como asesores, guardianes de calidad o herramientas de detección. Además, algunas herramientas realizan pruebas automatizadas sobre el código, simulando un intento de hackeo una vez que el software está en producción. Todas tienen su propio conjunto de ventajas y desafíos, y ninguna puede ofrecer una garantía general del 100 por ciento de que no existen amenazas de seguridad dentro de la aplicación. La medida preventiva número uno que puede emplear es que, cuanto antes pueda detectar la debilidad, más rápido y económico será subsanarla con el menor impacto en su empresa.

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

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

Si bien los CISO y los CIO se ven obligados esencialmente a desarrollar agresivamente sus capacidades empresariales de DevOps y DecSecOps, eso no significa que no haya tiempo para considerar e implementar las herramientas y la capacitación adecuadas en todos los equipos. Las habilidades de programación seguras serán un arma, no un obstáculo, para la innovación, y renunciar a ellas podría significar la destrucción absoluta de 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 las vulnerabilidades y mitigar los riesgos.

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

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

Table des matières

Télécharger le PDF
Veuillez consulter la ressource
Souhaitez-vous en savoir davantage ?

Directeur général, président et cofondateur

En savoir plus

Secure Code Warrior là pour aider votre organisation à protéger le code tout au long du cycle de vie du développement logiciel et à créer une culture où la cybersécurité est une priorité. Que vous soyez administrateur AppSec, développeur, CISO ou toute autre personne impliquée dans la sécurité, nous pouvons aider votre organisation à réduire les risques associés à un code non sécurisé.

Veuillez réserver une démonstration.Télécharger
Partager sur :
marques LinkedInSocialLogo x
Centre de ressources

Ressources pour débuter

Plus de publications
Centre de ressources

Ressources pour débuter

Plus de publications