Tue. Aug 27th, 2024

El factor más importante que afecta la evolución de la seguridad de las aplicaciones es la velocidad a la que cambia la tecnología. Gran parte de esto se debe a la generalización de la consumerización: las personas esperan que las nuevas tecnologías y las actualizaciones estén disponibles rápidamente porque esperan una experiencia de consumo perfecta.

Esta tendencia, combinada con la introducción más amplia del software como servicio (SaaS), ha dado lugar a ciclos de desarrollo rápidos e iterativos en los que se realizan cambios en el software semanalmente, diariamente e incluso cada hora. Las prácticas tradicionales de seguridad de aplicaciones no pueden seguir el ritmo. Aquí es donde entra DevSecOps.

DevSecOps es una mentalidad y una forma de trabajar dentro del campo de la seguridad de aplicaciones en el que la seguridad es parte del trabajo de todos, no solo de un equipo. Ayuda a la seguridad a escalar al mismo ritmo de cambio que los nuevos ciclos de desarrollo, al tiempo que eleva la importancia de la seguridad a la de las métricas de éxito comercial más tradicionales, como la disponibilidad o la calidad del producto.

Sin embargo, históricamente las empresas han tenido problemas para implementar DevSecOps dentro de sus organizaciones. Una de las barreras más persistentes es que puede ser un gran cambio cultural para los equipos de tecnología y, a menudo, implica un cambio en las herramientas. Pero cuando se hace bien, DevSecOps puede tener un impacto significativo en el fortalecimiento de la seguridad de las aplicaciones. Y si bien puede parecer contradictorio, la mejor estrategia es hacer que DevSecOps sea la responsabilidad de ingeniería – no seguridad.

¿Qué hace que DevSecOps sea tan difícil de adoptar?

Recientes incidentes de seguridad cibernética como Log4j y SolarWinds demostraron a los equipos de liderazgo ejecutivo que ya no pueden permitirse el lujo de mantener la seguridad en un silo. En su lugar, deben convertirlo en la base de la estrategia de la empresa desde la sala de juntas hasta el centro de desarrollo de software.

De la noche a la mañana, la falla de Log4j se convirtió en un problema para miles de empresas que utilizan el marco de registro de código abierto de Log4j en su software. Aunque la vulnerabilidad se parchó antes de que los actores de amenazas pudieran causar un daño importante, expuso cuánto se desconoce aún sobre las muchas piezas de software que forman parte de una amplia gama de sistemas.

Y aunque el ataque de SolarWinds afectó a las cadenas de suministro, apunta a un problema de visibilidad similar: demasiadas empresas no entienden completamente el alcance de sus operaciones de software o cómo su código afecta su perfil general de amenazas, lo que brinda la oportunidad para que los ciberdelincuentes se dirijan hacia atrás. herramientas de infraestructura final y otras vulnerabilidades no supervisadas.

DevSecOps puede ser difícil de implementar porque implica un cambio de mentalidad para los equipos de seguridad, ingenieros y desarrolladores. El escaneo de código, un enfoque común implementado como parte de DevSecOps, a menudo puede marcar falsos positivos. Esto, a su vez, crea trabajo innecesario para los desarrolladores y puede hacer que no quieran seguir los procedimientos de seguridad adecuados para verificar su código.

Mientras tanto, los equipos de seguridad a menudo luchan con una percepción de pérdida de control. Las empresas necesitan encontrar un mejor mecanismo para integrar la automatización con la experiencia humana para incorporar la seguridad dentro del proceso de desarrollo sin ralentizar las operaciones o minimizar la postura de seguridad general de la empresa.

¿Cómo pueden las empresas implementar DevSecOps?

La implementación de DevSecOps comienza con la comprensión de la cultura de la empresa y cómo operan los desarrolladores. Debido a su estructura de incentivos actual, muchos equipos de ingeniería se enfocan en facilitar la disponibilidad y la calidad del producto, pero la seguridad también afecta directamente estas métricas comerciales. Cuando las empresas limitan la seguridad al equipo de seguridad y delegan todo el resto del trabajo de desarrollo a la ingeniería, pierden la oportunidad de facilitar una colaboración verdaderamente productiva.

Si las organizaciones quieren que sus desarrolladores integren la seguridad en su trabajo diario, primero deben comprender los procesos, los puntos débiles y las motivaciones de sus desarrolladores. Responder estas preguntas puede ayudar a los equipos a integrar mejor la seguridad en el proceso de DevOps para trabajar para sus desarrolladores, no contra ellos.

También señala por qué DevSecOps debe convertirse en responsabilidad del equipo de ingeniería. Asegurarse de que la ingeniería tenga voz en el proceso de DevSecOps les da un sentido de propiedad sobre la seguridad y les permite elegir las herramientas que funcionarán mejor dentro de su entorno específico.

Poner la responsabilidad dentro de la ingeniería es el cambio clave para adoptar una mentalidad de DevSecOps.

¿Que sigue?

La velocidad a la que evoluciona la tecnología seguirá acelerándose. Como resultado, las organizaciones deben priorizar la visibilidad de la seguridad de las aplicaciones para mantenerse al día con estos cambios.

El volumen ya está aumentando sobre cómo las empresas pueden mejorar su visibilidad para comprender dónde implementar recursos para fortalecer su postura de seguridad, y ese volumen solo se ampliará con el tiempo. ¿Es una lista de materiales de software (SBOM) la respuesta? Si es así, ¿cuál es la mejor manera de crear y publicar ese SBOM?

En última instancia, la seguridad de las aplicaciones consiste en hacer lo correcto para los clientes. Si las empresas están creando y lanzando productos no seguros, dañan su reputación comercial. y clientes. DevSecOps integra la seguridad en el núcleo del éxito empresarial para que las empresas puedan hacer lo correcto por sus usuarios finales y por sí mismas. Para aumentar la adopción de DevSecOps en una organización, las empresas deben poner la responsabilidad de la seguridad en los equipos que crean sus soluciones.

Mandy Andress es directora de seguridad de la información en Elastic, una empresa de búsqueda empresarial, y tiene más de 25 años de experiencia en gestión de riesgos y seguridad de la información.

Related Post

Leave a Reply

Your email address will not be published. Required fields are marked *