Por qué la calidad y la seguridad son importantes en el software



Es hora de posicionar la calidad y la seguridad como iguales bajo la métrica de la integridad del computer software.

El software program ha revolucionado para siempre el desarrollo de productos tradicionales. Es lo que distingue a las empresas: la máxima ventaja competitiva. Pero esto se tiene que hacer bien.

No puede simplemente enviar program. Se espera que proporcione software seguro y de alta calidad para obtener beneficios comerciales cuantificables, como una mayor productividad y un menor costo total de propiedad (TCO). Y, en última instancia, el objetivo es mejorar la vida del usuario closing de una manera significativa.

Pero, ¿qué significa exactamente software de «calidad» y «seguro»? ¿El software package de buena calidad significa automáticamente que es seguro? Y si es realmente seguro, ¿puede considerarse inherentemente de alta calidad? ¿Son realmente lo mismo? Bueno, es complicado. Pero para los CISO responsables de garantizar la seguridad en todo el desarrollo de software, es fundamental desenredar estas preguntas.

Definir primero, medir segundo
Como no puede medir lo que no puede definir, comencemos con las definiciones. El software package de calidad «se ejecutará de acuerdo con el diseño y el propósito previstos según la funcionalidad comercial». El software package seguro «no pondrá los sistemas o los datos en riesgo de acceso no autorizado». Existe una relación clara entre los dos, una que se destaca en la guía de la autorizada Sociedad Estadounidense de Calidad, que posiciona la seguridad como elemento clave de la calidad del software program.

No es mi trabajo, no es mi problema
Podemos culpar a la historia por este dilema de calidad versus seguridad. Desde los días del desarrollo lineal en cascada, la calidad ha sido el rey para los equipos de desarrollo. No tenían que pensar en la seguridad, ese era el trabajo de la seguridad. Mientras tanto, la seguridad trabajaba por separado, pero tenía el trabajo poco envidiable de apresurarse a «atornillar» las soluciones a la hora 11, ralentizando las cosas y generando disputas entre los dos equipos.

Avance rápido hasta el día de hoy y es fácil ver por qué este modelo no vuela. Solo en la primera mitad de 2019, Se reportaron 3.813 infracciones, exponiendo más de 4.1 mil millones de registros y costando a las organizaciones de víctimas $ 3,2 millones de media. Y esas son solo las infracciones que conocemos. Las organizaciones simplemente no pueden permitirse el lujo de mantener la seguridad en el asiento trasero: los riesgos comerciales y de reputación son demasiado altos.

Llámalos como quieras, todos son problemas
Es un hecho que los humanos cometemos errores. Además, muchos equipos simplemente no tienen las herramientas o capacidades para permitir la creación de código sin errores. Agregue presión constante para moverse cada vez más rápido y los problemas de calidad pueden convertirse rápidamente en pesadillas de seguridad. Muchas infracciones se pueden rastrear a errores (que hacen que el software se desvíe de su propósito) o defectos de calidad subyacentes (como la falla al delinear correctamente el código de los datos o validar y filtrar suficientemente la entrada). Incluso si el código está diseñado a la perfección, es solo un ataque de secuencia de comandos entre sitios (XSS) de una brecha de seguridad. Es seguro decir que una inyección de código malicioso no es solo un problema de seguridad. También es un problema de calidad importante.

Las empresas crean software para satisfacer las necesidades del cliente. Esa es la función empresarial principal del software program. Si podemos estar de acuerdo en que esto es cierto, entonces es seguro asumir que ignorar el software package no seguro no es una opción.

Cuatro pasos hacia DevSecOps
La seguridad debe convertirse en responsabilidad de todos. A medida que el desarrollo, la seguridad y las operaciones comienzan a combinarse y alinearse para abordar las realidades actuales, la seguridad finalmente está reclamando el lugar que le corresponde, al lado de la calidad. Aunque todavía es relativamente nuevo, DevSecOps la metodología está ganando terreno con el 8% de las empresas asegurando el 75% o más de sus aplicaciones nativas de la nube con prácticas de DevSecOps en la actualidad, una cifra que se espera que aumente al 68% en dos años.

Pero esto no sucede de la noche a la mañana. Adoptar este nuevo modelo requiere un cambio cultural significativo: los desarrolladores deben aceptar la noción de que el software de calidad depende de la seguridad incorporada en cada fase del desarrollo. No solo eso, necesitan ver la seguridad como una parte importante de su propio trabajo.

Aquí hay cuatro pasos específicos que puede seguir su organización ahora mismo para comenzar a cambiar la mentalidad e impulsar la transformación:

  • Adopte un enfoque de arriba hacia abajo. «La seguridad es el trabajo de todos». Esta mentalidad debe comenzar en (y provenir) de la cima.
  • Involucrar la seguridad en la formación de desarrolladores. Por ejemplo, lleve a cabo educación «publish-mortem», compartiendo repositorios de código fuente y estableciendo bibliotecas de autenticación / cifrado.
  • Incorpore seguridad consistente en todo el desarrollo. Integre el análisis de seguridad de forma coherente en todo el ciclo de vida del desarrollo de software package (SDLC) y supervise todos los problemas de forma uniforme y centralizada para cerrar las brechas de detección y mantener una visión completa del riesgo.
  • Aprovecha la automatización. La implementación de pruebas automatizadas en cada confirmación de código lo ayudará a detectar vulnerabilidades antes y eliminar el ruido para que los desarrolladores puedan priorizar los esfuerzos.

La calidad debe traducirse en productos seguros. A medida que DevSecOps se afianza, es hora de posicionar la calidad y la seguridad como iguales bajo la métrica de la integridad del application. Y los CISO, depende de usted articular el valor de esta relación simbiótica con su organización, asegurando que el application pueda cumplir con su función comercial fundamental de satisfacer y proteger al cliente en igual medida.

Contenido relacionado:

John Worrall tiene más de 25 años de liderazgo, estrategia y experiencia operativa en marcas de ciberseguridad establecidas y en etapas iniciales. En su puesto true como CEO en ZeroNorth, lidera los esfuerzos de la compañía para ayudar a los clientes a reforzar la seguridad durante la vida del software … Ver biografía completa

Lectura recomendada:

Más información





Enlace a la noticia initial