Los clientes nos exigen productos cada vez más seguros y que estén listos para trabajar con ellos, por lo que la seguridad es una de las principales prioridades de todos. Pero sin un enfoque estándar de seguridad, es casi imposible cumplir con las expectativas de los clientes.
Ahí es donde entra en juego el ciclo de vida de desarrollo seguro (SDL).
SDL es un proceso. Si observa los muchos de los SDL que existen en todas las industrias, encontrará que la mayoría incluye las mismas fases y actividades de seguridad básicas. Pueden tener diferentes nombres para cada fase, pero todas las industrias siguen básicamente el mismo proceso.
Aquí exponemos la guía que sigue BLMovil para colocar la seguridad al frente de nuestros desarrollo y al centro de nuestra metodología.
Definición del ciclo de vida del desarrollo seguro
En su forma más simple, el SDL es un proceso que estandariza las mejores prácticas de seguridad en una variedad de productos y / o aplicaciones. Captura las actividades de seguridad estándar de la industria y las empaqueta para que puedan implementarse fácilmente. El ciclo de vida del desarrollo de software consta de varias fases, que explicamos con más detalle a continuación.
El SDL se desarrolló por parte de Microsoft, como respuesta al famoso memorando de Bill Gates de enero de 2002. En él, Gates estableció el requisito de incorporar seguridad en los productos de Microsoft. Admitió que debido a varios brotes de virus y malware, Microsoft tenía que incorporar la seguridad si quería ser tomado en serio en el mercado.
Esto dio como resultado el esfuerzo de Microsoft Trustworthy Computing, del cual nació la idea de SDL. Microsoft hizo obligatorio el SDL en 2004 y se desató una industria artesanal. Muchas otras empresas, incluidas Cisco, Adobe y Aetna, han adoptado desde entonces los procesos SDL de Microsoft o han creado los suyos propios. Y Microsoft ha compartido sus éxitos y experiencias sobre el SDL con otras empresas y publicado muchos de sus materiales y herramientas como código abierto.
Los problemas que resuelve SDL
La falta de un enfoque estándar para desarrollar productos seguros termina causando problemas. Por un lado, las vulnerabilidades van creciendo en los productos desarrollados. La tipificación de los mismos y la respuesta que tiene que dar el equipo de desarrollo para hacer frente a estas vulnerabilidades son grandes consumidores de recursos. Como resultado, los programadores pasan demasiado tiempo arreglando el código que escribieron en el pasado y no pueden enfocarse en los desarrollos futuros.
El segundo problema es que los programadores tienden a repetir los mismos errores de seguridad, esperando cada vez una respuesta diferente. El tercer problema viene de que los problemas se encuentran en el lanzamiento o después de la implementación, cuando si se hubieran solucionado antes, los problemas se podrían haber solucionado de una forma más económica.
Finalmente, sin un estándar de seguridad, los clientes no tienen garantía de que un producto determinado sea seguro. Un producto puesto a la venta puede ser perfecto o puede ser terrible desde el punto de vista de la seguridad. Sin SDL, no existe paridad de seguridad de producto a lo largo de la producción dentro de la empresa. Y sin un proceso estándar, algunos equipos de desarrollo ignoran la seguridad por completo.
Personas, procesos y tecnología
El SDL es un proceso con diferentes fases que contiene actividades de seguridad que se encuentra dentro del clásico triángulo personas-proceso-tecnología. El SDL forma la parte del proceso.
Incluye tanto al equipo de seguridad central que gestiona el proceso y lo actualiza, como a los equipos de producto o desarrollo que realizan actividades de seguridad. La parte de la tecnología se basa en herramientas que ayudan a encontrar vulnerabilidades en el código fuente o descubrir vulnerabilidades en una instancia en ejecución del producto o aplicación.
El SDL tiene que ser neutral a la metodología utilizada. Las actividades de seguridad encajan dentro de cualquier metodología de desarrollo de productos, ya sea en cascada, ágil o DevOps. Las diferencias metodológicas se manifiestan en la cadencia de las actividades de seguridad.
El SDL se desarrolló durante el tiempo en el que predominaba la metodología en cascada, por lo que generalmente se describe como un proceso lineal que comienza con los requisitos y termina con el lanzamiento. Cuando el SDL se amplía a ágil, algunas actividades de seguridad se integran en el cronograma de sprint normal, mientras que otras se realizan en procesos aparte. Con DevOps, las actividades se integran en el proceso de compilación mediante la automatización, mientras que las actividades adicionales ocurren fuera del workflow.
Un SDL se divide en fases que se relacionan estrechamente con el enfoque en cascada. El enfoque estándar de SDL incluye requisitos, diseño, implementación, prueba y lanzamiento / respuesta.
Fase de requisitos
En la fase de requisitos, se integran las mejores prácticas de seguridad para el desarrollo de un producto. Estas prácticas pueden venir de los estándares de la industria o estar basadas en respuestas a problemas que han ocurrido en el pasado.
Existen requisitos predefinidos para ayudar definir los requisitos de seguridad funcional implementados en el producto e incluir todas las actividades del SDL. Se utilizan como punto de reforzamiento para garantizar que todas las piezas se consideren correctamente.
Los requisitos de seguridad pueden adoptar la forma clásica, indicando que el producto o la aplicación debe, puede o debe hacer algo. Un ejemplo podría ser que el producto deba exigir una longitud mínima de contraseña de ocho caracteres.
En el mundo ágil, los requisitos se expresan como historias de usuarios. Estas historias contienen la misma información que los requisitos, pero la funcionalidad de seguridad está escrita desde la perspectiva del usuario.
Fase de diseño
La fase de diseño dentro del SDL consiste en actividades que deben ocurrir antes de escribir el código. El diseño seguro consiste en cuantificar una arquitectura (para una sola característica o para todo el producto) y luego buscar problemas. El diseño seguro se debe realizar en documento formal para que quede documentado todo el proceso realziado.
En el desarrollo de muchos sistemas, el avión está en el aire mientras se diseñan las alas, pero el SDL puede sobrevivir incluso a esta locura. La clave es utilizar el modelado de amenazas.
El modelado de amenazas es el proceso de pensar en cómo se atacará una característica o sistema y luego mitigar esos ataques futuros en el diseño antes de escribir el código. El modelado de amenazas es similar a percibir los delitos antes de que ocurran, como en la película Minority Report de 2002.
Un modelo de amenazas sólido identifica la zona de ataque de una característica o producto y luego define los ataques más probables que podrían ocurrir en esas interfaces. Un modelo de amenaza es tan bueno como las mitigaciones que contiene para solucionar los problemas. Pero es fundamental identificar los problemas de seguridad en las primeras etapas del proceso.
Fase de Implementación o codificación
La siguiente fase es la implementación o escritura de código seguro. El SDL contiene un listado de elementos que deben contemplar los programadores para asegurarse de que su código tenga la mayor probabilidad de ser seguro. Este proceso involucra una mezcla de estándares y herramientas automatizadas.
Un SDL sólido define una guía de codificación segura (como las publicadas por SEI CERT para C, C ++ y Java), que define lo que se espera durante el desarrrollo y proporciona una guía para ayudar a los desarrolladores cuando identifican un problema específico y necesitan información para solucionarlo.
Las herramientas de implementación incluyen software de pruebas de seguridad de aplicaciones estáticas (SAST) y pruebas de seguridad de aplicaciones dinámicas (DAST). SAST es como un corrector ortográfico de código que identifica vulnerabilidades potenciales en el código fuente. SAST se ejecuta en una compilación nocturna o puede integrarse en su IDE. Puede encontrar y abrir nuevos errores en el sistema de administración de errores todas las noches (en nuestro caso se generan en Polarion) o pedirle al desarrollador que haga una pausa mientras codifica para solucionar un problema en tiempo real.
El DAST comprueba la instanciación en tiempo de ejecución de la aplicación. Rastrea una aplicación completamente para identificar todas las interfaces posibles y luego intenta explotar las vulnerabilidades comunes de dichos interfaces en la aplicación.
Fase de prueba
Las actividades de prueba formales dentro del SDL tienen que incluir planes de prueba funcional de seguridad, escaneo de vulnerabilidades y pruebas de penetración. El análisis de vulnerabilidades utiliza herramientas estándar de la industria para determinar si existe alguna vulnerabilidad a nivel del sistema con la aplicación o el producto.
Las pruebas de penetración en las que los testers intentan evitar las protecciones de seguridad en una aplicación determinada y explotarlas. El Pen Testing extiende el producto y lo expone a escenarios de prueba que las herramientas automatizadas no pueden replicar. El Pen Testing requiere muchos recursos, por lo que generalmente no se realiza en cada versión.
Fase final: Liberación (Release) / respuesta
El lanzamiento ocurre cuando todas las actividades de seguridad se validan contra la compilación final y es en ese momento cuando el software se envía a los clientes (o se pone a disposición para su descarga).
La respuesta es la interfaz que generamos para que los clientes externos y nuestrosexpertos de seguridad puedan informar sobre problemas de seguridad en los productos.
Parte de la respuesta incluye un equipo de respuesta a incidentes de seguridad del producto que se centra en clasificar y comunicar las vulnerabilidades del producto, tanto errores individuales como aquellos que requerirán la colaboración de toda la industria para informar si hiciera falta a terceros de problemas de seguridad en sus productos como Frameworks, plugins, etc, para que los puedan solucionar para poder seguir utilizándolos con seguridad en nuestros desarrollos.
Hay otras actividades de seguridad que son cruciales para el éxito de un SDL. Como pueden ser recompensas por errores, educación y capacitación.
Pensamos diferente, pensamos seguro
El ciclo de vida de desarrollo seguro es una forma diferente de crear productos; coloca la seguridad al frente y al centro durante el proceso de desarrollo de productos o aplicaciones.
Desde los requisitos hasta el diseño, desde la codificación hasta las pruebas, SDL nos esforzamos por incorporar seguridad en nuestros productos o aplicaciones en cada paso del proceso de desarrollo. Una software factory moderna no puede sobrevivir sin tomarse en serio la seguridad, y la forma de hacerlo es integrando un SDL en nuestro trabajo diario.
Si tienes una idea, nosotros te la desarrollamos