Cómo los CISOs y CIOs creativos pueden innovar y transformar su programa de seguridad

Publicado el 23 de julio de 2019
por Pieter Danhieux
ESTUDIO DE CASO

Cómo los CISOs y CIOs creativos pueden innovar y transformar su programa de seguridad

Publicado el 23 de julio de 2019
por Pieter Danhieux
Ver recurso
Ver recurso

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

Si bien los CISO y los CIO tienen la poco envidiable posición de asumir la parte del león de la responsabilidad de la seguridad del software, especialmente en el caso de una vergonzosa violación de los datos de la empresa, también se les ofrece una oportunidad única de creciente relevancia: son los nuevos innovadores, y pueden ser muy influyentes con el enfoque correcto. Todas las organizaciones del planeta, tanto públicas como comerciales, luchan por conservar (y ganar) su espacio en el mercado en un mundo que se digitaliza rápidamente. Los clientes esperan una experiencia en línea sin fisuras tanto de los productos pasados como de los futuros, y un enfoque empresarial "digital-first" se está convirtiendo en algo obligatorio. Al fin y al cabo, si no se cumplen estas expectativas, es casi seguro que habrá un competidor dispuesto a aprovechar la oportunidad.

Entonces, ¿qué significa esto para el CISO o CIO moderno? Naturalmente, significa que están empleando 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, aunque ha sido una consideración principal durante muchos años, es un factor de riesgo creciente a medida que se realizan cada vez más operaciones empresariales en línea y en el punto de mira de los atacantes. Las implicaciones de una brecha son enormes, pero optar por la digitalización no es una opción.

Los CISOs y CIOs creativos están en una posición privilegiada para seguir forjando el camino de nuestros futuros digitales, junto con sus equipos de AppSec y de desarrollo. No cabe duda de que darán forma a la innovación a largo plazo de las empresas, los gobiernos y los servicios públicos en línea, pero tienen la gran 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 alcanzar. Ha dado lugar a equipos de desarrollo que a menudo están fragmentados, con un enfoque principal general en la entrega de características y funciones, sin tener en cuenta las vulnerabilidades que podrían estar creando en el código que están produciendo tan rápidamente. Los especialistas en seguridad de las aplicaciones corrigen constantemente los mismos errores, mientras que la amenaza de una brecha por una puerta trasera relativamente sencilla que se deja abierta se cierne sobre ellos.

Si queremos 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 ver las catastróficas consecuencias a las que se enfrentó Marriott como resultado de su brecha de 2018: Una multa por el GDPR de más de 123 millones de dólares, más de 500 millones de registros robados y una reputación de seguridad en ruinas. Este desastre se produjo 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 Starwoods, una empresa adquirida por Marriott en 2016. Su uso posterior del software quedó claramente sin revisar desde la perspectiva de la seguridad de las aplicaciones. Esto dio a los atacantes maliciosos 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 CIOs y CISOs necesitan considerar el estado de sus propios climas de seguridad de software muy cuidadosamente. ¿Cuánta conciencia de seguridad tiene el desarrollador medio? ¿En qué medida trabajan juntos los equipos de seguridad de aplicaciones y de desarrollo? No hay una solución "mágica", pero se puede trabajar y mejorar la cultura, la formación y el apoyo. Los equipos de desarrollo pueden pasar de ser la primera línea de riesgo de violación de datos en la organización, a ser los superhéroes de la seguridad que detienen el código malo antes de que pase a producción.

Comprobación de la salud de la codificación segura: ¿Está la suya con soporte vital?

¿Dónde encaja su propio equipo de desarrollo? He creado esta lista de comprobación de la 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 un código más rápido, mejor y más seguro (o, de hecho, si necesita una revisión del programa de seguridad):

1. ¿En qué medida le apoya el resto de su C-Suite? ¿Entienden que la seguridad tradicional de la red ya no es suficiente?

En el futuro del software, asegurar la capa de red utilizando medidas de seguridad anticuadas simplemente no es suficiente (y, seamos sinceros, rara vez tiene éxito de todos modos) incluso contra los hackers semiprofesionales. Entre muchos informes consistentes, el "2017 Data Breach Investigations Report" de Verizon cita que un asombroso 35 por ciento de las violaciones de datos hoy en día 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 e inculcar la capa de protección básica y fundamental de las medidas de AppSec podría dejarle muy expuesto a una brecha.

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

El enfoque actual de la seguridad de las aplicaciones está bastante cargado de herramientas y se centra en ir 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 un resultado de detección y reacción. Los equipos de seguridad buscan y detectan vulnerabilidades en el código que ya está escrito, reaccionando para arreglar el código comprometido en lugar de asegurarse de que está libre de errores mientras se elabora. Según el Instituto Nacional de Estándares y Tecnología(NIST), es 30 veces más caro detectar y arreglar las vulner abilidades 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, la doble manipulación y el tiempo empleado en 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 los campeones de la seguridad dentro de la cohorte de desarrolladores, al tiempo que da al equipo de desarrollo las herramientas y la formación adecuadas para crecer y actuar con una mentalidad de codificación segura. Hay un enfoque en el auto-desarrollo continuo, y la flexión de sus músculos de resolución de problemas para que puedan ser la primera línea de defensa en su organización, evitando que las vulnerabilidades comunes se produzcan en primer lugar.

3. ¿Se está esforzando por desarrollar habilidades prácticas de seguridad, o se limita a alimentar el conocimiento en un solo sentido?

La gran mayoría de las soluciones de formación en seguridad (online y CBT) se centran en la creación de 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 contextual y práctico que les anime activamente a seguir formándose y desarrollando sus habilidades en un entorno real. Necesitan aprender sobre las vulnerabilidades recientemente identificadas, con ejemplos de código real, y poder trabajar en sus lenguajes y marcos de trabajo preferidos. Esta experiencia de aprendizaje es eficaz para ayudarles a comprender cómo localizar, identificar y corregir las vulnerabilidades conocidas en el código en el que trabajan activamente en el curso de sus trabajos.

Aunque hay muchos profesores con conocimientos y mucha información sobre cómo solucionar las vulnerabilidades de seguridad, hojear libros de texto o ver horas de vídeo no consigue captar la mente de muchos desarrolladores creativos y resolutivos, y si el flujo constante de filtraciones de datos es una indicación, sigue siendo en gran medida ineficaz para evitar que las vulnerabilidades entren en el código.

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

Un paso fundamental para garantizar que el equipo de desarrollo adopte una mentalidad que dé prioridad a la seguridad es recopilar y revisar las pruebas. Esto no debe ser una suposición o un juego de adivinanzas: los desarrolladores tienen una mentalidad de seguridad o no la tienen.

Las métricas pretenden demostrar al desarrollador y a su organización que su duro 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. Debe haber evaluaciones pertinentes, y estas deben 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 una mejora continua.

Con demasiada frecuencia, la formación en materia de seguridad se convierte en un ejercicio de "marcar la casilla" para las organizaciones, sin hacer hincapié en garantizar que esta formación ha sido eficaz, que se ha comprometido con ella o incluso que la ha retenido.

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

Muchas organizaciones deciden contratar el trabajo de desarrollo a agencias de terceros. Tanto si existen en el país como en el extranjero, sus capacidades y prácticas generales de codificación segura son un relativo misterio para su cliente. 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 que exige que el producto final sea "seguro". Muy pocas empresas toman medidas para verificar las habilidades de estas empresas de desarrollo por adelantado, por lo que corren el riesgo de que se les entregue un software que funcione tal y como se les informó, pero que ha sido construido sin seguir prácticas de codificación seguras. Peor aún, si la empresa compradora no es consciente de los fallos de seguridad inherentes a la aplicación, se arriesga a enviar un software vulnerable.

El escenario más común es que cualquier vulnerabilidad sea detectada por especialistas en seguridad dedicados (individuos que son difíciles de encontrar y que tienen un alto coste), usted se enfrenta a un retraso en la fecha de puesta en marcha, y a posibles discusiones contractuales sobre quién tiene que pagar por arreglar estas debilidades de seguridad. Sin embargo, si es inteligente por adelantado y evalúa las habilidades de seguridad de la aplicación de los desarrolladores que van a construir su próxima aplicación, se ahorrará muchos retrasos potenciales, frustración y dinero.

6. ¿Sus desarrolladores conocen los puntos débiles de seguridad más comúnmente explotados?

Más del 85 por ciento de las vulnerabilidades de las aplicaciones web explotadas se atribuyen a sólo 10 vulnerabilidades conocidas "las 10 principales de OWASP". Como mínimo, la formación en seguridad de sus aplicaciones debe cubrirlas, además de muchos otros tipos de vulnerabilidades. Los retos de formación a los que se enfrentan sus desarrolladores deben ser revisados y actualizados regularmente, con nuevos retos para nuevos marcos de codificación o nuevos tipos de vulnerabilidad.

La formación de precisión utilizando escenarios de codificación segura del mundo real debería ser la norma; un conocimiento general vago simplemente no es eficaz. (¿Se pregunta cómo podrían ser estos escenarios de codificación segura? Echa un vistazo a nuestra serie de blogs Coders Conquer Security; hay un reto jugable en cada entrada).

7. ¿Dispone de campeones de seguridad internos?

Todas las organizaciones con gran número de desarrolladores deberían invertir en un campeón de seguridad: alguien que se responsabilice de mantener un alto nivel de seguridad dentro del equipo de desarrollo. Su propósito es ser un punto de contacto de apoyo para cualquier persona que tenga preguntas sobre la seguridad, así como convertirse en el principal defensor de seguir las mejores prácticas de seguridad.

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

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

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

Hay herramientas disponibles en cada etapa del SDLC que servirán como asesores, guardianes de la calidad o herramientas de detección. Además, algunas herramientas ejecutan pruebas automatizadas sobre el código, simulando intentos de piratería una vez que el software está en producción. Todas tienen sus propias ventajas y dificultades, y ninguna puede garantizar al cien por cien que no existan amenazas de seguridad en la aplicación. La principal medida preventiva que se puede emplear es que cuanto antes se pueda detectar el punto débil, más rápido y barato será remediarlo con el menor impacto posible en la empresa.

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

¿Qué tal le fue a su organización con respecto a la lista de control anterior?

Si bien los CISO y los CIO se ven obligados a desarrollar de forma agresiva sus capacidades empresariales de DevOps y DecSecOps, eso no significa que no haya tiempo para considerar e implementar las herramientas y la formación adecuadas en todos los equipos. Las habilidades de codificación segura 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 mucho más barata a largo plazo para reducir las vulnerabilidades y mitigar el riesgo.

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

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

Ver recurso
Ver recurso

Autor

Pieter Danhieux

Pieter Danhieux es un experto en seguridad mundialmente reconocido, con más de 12 años de experiencia como consultor de seguridad y 8 años como instructor principal de SANS enseñando técnicas ofensivas sobre cómo atacar y evaluar organizaciones, sistemas y personas en busca de debilidades de seguridad. En 2016, fue reconocido como una de las personas más cool de la tecnología en Australia (Business Insider), galardonado como Profesional de Seguridad Cibernética del Año (AISA - Asociación Australiana de Seguridad de la Información) y tiene certificaciones GSE, CISSP, GCIH, GCFA, GSEC, GPEN, GWAPT, GCIA.

¿Quieres más?

Sumérjase en nuestras últimas ideas sobre codificación segura en el blog.

Nuestra amplia biblioteca de recursos tiene como objetivo potenciar el enfoque humano de la mejora de la codificación segura.

Ver blog
¿Quieres más?

Obtenga las últimas investigaciones sobre la seguridad impulsada por los desarrolladores

Nuestra amplia biblioteca de recursos está repleta de recursos útiles, desde libros blancos hasta seminarios web, que le ayudarán a iniciarse en la codificación segura orientada a los desarrolladores. Explórela ahora.

Centro de recursos

Cómo los CISOs y CIOs creativos pueden innovar y transformar su programa de seguridad

Publicado el 23 de julio de 2019
Por Pieter Danhieux

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

Si bien los CISO y los CIO tienen la poco envidiable posición de asumir la parte del león de la responsabilidad de la seguridad del software, especialmente en el caso de una vergonzosa violación de los datos de la empresa, también se les ofrece una oportunidad única de creciente relevancia: son los nuevos innovadores, y pueden ser muy influyentes con el enfoque correcto. Todas las organizaciones del planeta, tanto públicas como comerciales, luchan por conservar (y ganar) su espacio en el mercado en un mundo que se digitaliza rápidamente. Los clientes esperan una experiencia en línea sin fisuras tanto de los productos pasados como de los futuros, y un enfoque empresarial "digital-first" se está convirtiendo en algo obligatorio. Al fin y al cabo, si no se cumplen estas expectativas, es casi seguro que habrá un competidor dispuesto a aprovechar la oportunidad.

Entonces, ¿qué significa esto para el CISO o CIO moderno? Naturalmente, significa que están empleando 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, aunque ha sido una consideración principal durante muchos años, es un factor de riesgo creciente a medida que se realizan cada vez más operaciones empresariales en línea y en el punto de mira de los atacantes. Las implicaciones de una brecha son enormes, pero optar por la digitalización no es una opción.

Los CISOs y CIOs creativos están en una posición privilegiada para seguir forjando el camino de nuestros futuros digitales, junto con sus equipos de AppSec y de desarrollo. No cabe duda de que darán forma a la innovación a largo plazo de las empresas, los gobiernos y los servicios públicos en línea, pero tienen la gran 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 alcanzar. Ha dado lugar a equipos de desarrollo que a menudo están fragmentados, con un enfoque principal general en la entrega de características y funciones, sin tener en cuenta las vulnerabilidades que podrían estar creando en el código que están produciendo tan rápidamente. Los especialistas en seguridad de las aplicaciones corrigen constantemente los mismos errores, mientras que la amenaza de una brecha por una puerta trasera relativamente sencilla que se deja abierta se cierne sobre ellos.

Si queremos 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 ver las catastróficas consecuencias a las que se enfrentó Marriott como resultado de su brecha de 2018: Una multa por el GDPR de más de 123 millones de dólares, más de 500 millones de registros robados y una reputación de seguridad en ruinas. Este desastre se produjo 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 Starwoods, una empresa adquirida por Marriott en 2016. Su uso posterior del software quedó claramente sin revisar desde la perspectiva de la seguridad de las aplicaciones. Esto dio a los atacantes maliciosos 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 CIOs y CISOs necesitan considerar el estado de sus propios climas de seguridad de software muy cuidadosamente. ¿Cuánta conciencia de seguridad tiene el desarrollador medio? ¿En qué medida trabajan juntos los equipos de seguridad de aplicaciones y de desarrollo? No hay una solución "mágica", pero se puede trabajar y mejorar la cultura, la formación y el apoyo. Los equipos de desarrollo pueden pasar de ser la primera línea de riesgo de violación de datos en la organización, a ser los superhéroes de la seguridad que detienen el código malo antes de que pase a producción.

Comprobación de la salud de la codificación segura: ¿Está la suya con soporte vital?

¿Dónde encaja su propio equipo de desarrollo? He creado esta lista de comprobación de la 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 un código más rápido, mejor y más seguro (o, de hecho, si necesita una revisión del programa de seguridad):

1. ¿En qué medida le apoya el resto de su C-Suite? ¿Entienden que la seguridad tradicional de la red ya no es suficiente?

En el futuro del software, asegurar la capa de red utilizando medidas de seguridad anticuadas simplemente no es suficiente (y, seamos sinceros, rara vez tiene éxito de todos modos) incluso contra los hackers semiprofesionales. Entre muchos informes consistentes, el "2017 Data Breach Investigations Report" de Verizon cita que un asombroso 35 por ciento de las violaciones de datos hoy en día 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 e inculcar la capa de protección básica y fundamental de las medidas de AppSec podría dejarle muy expuesto a una brecha.

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

El enfoque actual de la seguridad de las aplicaciones está bastante cargado de herramientas y se centra en ir 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 un resultado de detección y reacción. Los equipos de seguridad buscan y detectan vulnerabilidades en el código que ya está escrito, reaccionando para arreglar el código comprometido en lugar de asegurarse de que está libre de errores mientras se elabora. Según el Instituto Nacional de Estándares y Tecnología(NIST), es 30 veces más caro detectar y arreglar las vulner abilidades 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, la doble manipulación y el tiempo empleado en 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 los campeones de la seguridad dentro de la cohorte de desarrolladores, al tiempo que da al equipo de desarrollo las herramientas y la formación adecuadas para crecer y actuar con una mentalidad de codificación segura. Hay un enfoque en el auto-desarrollo continuo, y la flexión de sus músculos de resolución de problemas para que puedan ser la primera línea de defensa en su organización, evitando que las vulnerabilidades comunes se produzcan en primer lugar.

3. ¿Se está esforzando por desarrollar habilidades prácticas de seguridad, o se limita a alimentar el conocimiento en un solo sentido?

La gran mayoría de las soluciones de formación en seguridad (online y CBT) se centran en la creación de 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 contextual y práctico que les anime activamente a seguir formándose y desarrollando sus habilidades en un entorno real. Necesitan aprender sobre las vulnerabilidades recientemente identificadas, con ejemplos de código real, y poder trabajar en sus lenguajes y marcos de trabajo preferidos. Esta experiencia de aprendizaje es eficaz para ayudarles a comprender cómo localizar, identificar y corregir las vulnerabilidades conocidas en el código en el que trabajan activamente en el curso de sus trabajos.

Aunque hay muchos profesores con conocimientos y mucha información sobre cómo solucionar las vulnerabilidades de seguridad, hojear libros de texto o ver horas de vídeo no consigue captar la mente de muchos desarrolladores creativos y resolutivos, y si el flujo constante de filtraciones de datos es una indicación, sigue siendo en gran medida ineficaz para evitar que las vulnerabilidades entren en el código.

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

Un paso fundamental para garantizar que el equipo de desarrollo adopte una mentalidad que dé prioridad a la seguridad es recopilar y revisar las pruebas. Esto no debe ser una suposición o un juego de adivinanzas: los desarrolladores tienen una mentalidad de seguridad o no la tienen.

Las métricas pretenden demostrar al desarrollador y a su organización que su duro 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. Debe haber evaluaciones pertinentes, y estas deben 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 una mejora continua.

Con demasiada frecuencia, la formación en materia de seguridad se convierte en un ejercicio de "marcar la casilla" para las organizaciones, sin hacer hincapié en garantizar que esta formación ha sido eficaz, que se ha comprometido con ella o incluso que la ha retenido.

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

Muchas organizaciones deciden contratar el trabajo de desarrollo a agencias de terceros. Tanto si existen en el país como en el extranjero, sus capacidades y prácticas generales de codificación segura son un relativo misterio para su cliente. 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 que exige que el producto final sea "seguro". Muy pocas empresas toman medidas para verificar las habilidades de estas empresas de desarrollo por adelantado, por lo que corren el riesgo de que se les entregue un software que funcione tal y como se les informó, pero que ha sido construido sin seguir prácticas de codificación seguras. Peor aún, si la empresa compradora no es consciente de los fallos de seguridad inherentes a la aplicación, se arriesga a enviar un software vulnerable.

El escenario más común es que cualquier vulnerabilidad sea detectada por especialistas en seguridad dedicados (individuos que son difíciles de encontrar y que tienen un alto coste), usted se enfrenta a un retraso en la fecha de puesta en marcha, y a posibles discusiones contractuales sobre quién tiene que pagar por arreglar estas debilidades de seguridad. Sin embargo, si es inteligente por adelantado y evalúa las habilidades de seguridad de la aplicación de los desarrolladores que van a construir su próxima aplicación, se ahorrará muchos retrasos potenciales, frustración y dinero.

6. ¿Sus desarrolladores conocen los puntos débiles de seguridad más comúnmente explotados?

Más del 85 por ciento de las vulnerabilidades de las aplicaciones web explotadas se atribuyen a sólo 10 vulnerabilidades conocidas "las 10 principales de OWASP". Como mínimo, la formación en seguridad de sus aplicaciones debe cubrirlas, además de muchos otros tipos de vulnerabilidades. Los retos de formación a los que se enfrentan sus desarrolladores deben ser revisados y actualizados regularmente, con nuevos retos para nuevos marcos de codificación o nuevos tipos de vulnerabilidad.

La formación de precisión utilizando escenarios de codificación segura del mundo real debería ser la norma; un conocimiento general vago simplemente no es eficaz. (¿Se pregunta cómo podrían ser estos escenarios de codificación segura? Echa un vistazo a nuestra serie de blogs Coders Conquer Security; hay un reto jugable en cada entrada).

7. ¿Dispone de campeones de seguridad internos?

Todas las organizaciones con gran número de desarrolladores deberían invertir en un campeón de seguridad: alguien que se responsabilice de mantener un alto nivel de seguridad dentro del equipo de desarrollo. Su propósito es ser un punto de contacto de apoyo para cualquier persona que tenga preguntas sobre la seguridad, así como convertirse en el principal defensor de seguir las mejores prácticas de seguridad.

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

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

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

Hay herramientas disponibles en cada etapa del SDLC que servirán como asesores, guardianes de la calidad o herramientas de detección. Además, algunas herramientas ejecutan pruebas automatizadas sobre el código, simulando intentos de piratería una vez que el software está en producción. Todas tienen sus propias ventajas y dificultades, y ninguna puede garantizar al cien por cien que no existan amenazas de seguridad en la aplicación. La principal medida preventiva que se puede emplear es que cuanto antes se pueda detectar el punto débil, más rápido y barato será remediarlo con el menor impacto posible en la empresa.

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

¿Qué tal le fue a su organización con respecto a la lista de control anterior?

Si bien los CISO y los CIO se ven obligados a desarrollar de forma agresiva sus capacidades empresariales de DevOps y DecSecOps, eso no significa que no haya tiempo para considerar e implementar las herramientas y la formación adecuadas en todos los equipos. Las habilidades de codificación segura 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 mucho más barata a largo plazo para reducir las vulnerabilidades y mitigar el riesgo.

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

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

Nos gustaría contar con su permiso para enviarle información sobre nuestros productos y/o temas relacionados con la codificación segura. Siempre trataremos sus datos personales con el máximo cuidado y nunca los venderemos a otras empresas con fines de marketing.

Enviar
Para enviar el formulario, habilite las cookies "Analytics". Siéntase libre de desactivarlas de nuevo una vez que haya terminado.